Is EA About The Business Or Just IT?

As all the hype around business architecture increases, a lot of clients are asking about EA’s relevance to the business. One newly minted EA put it this way: “I get the distinct impression that the business side of EA gets at best lip service. It’s no wonder business leaders criticize architects for being IT centric rather than business driven. But doesn’t the “E” mean enterprise?”

Architects ARE guilty of being IT centric, but that is changing. In our defense we have come by this bias legitimately:

• From the very beginning (see Zachman’s first article: http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf) EA clearly included a business component. But until recently the concept of business architecture was: “what IT needs to know about the business.” So in theory EA is about the enterprise but in practice has been very technology centric.

• Because EA was originally designed by technologists for technologists EA has grown up in IT further contributing to the idea that it is about technology.

• Because it has grown up in IT, EA practitioners are almost all technologists who are very comfortable in the technology space but not so comfortable in the business space. In fact, architects are often their own worst enemy when it comes to the business. They spend very little time with business leaders (outside of a specific project context) and spend even less time educating themselves about business (see my April 21st, 2009 blog post).

• Architects are taught that EA is fundamentally an engineering exercise but businesses are growing, evolving, mutating, complex systems. The traditional engineering model of EA doesn’t translate well to the business.

So what should architects be doing to create a more business driven architecture?

• Learn how to apply EA concepts in the business space including how to work with business tools that support BA such as capability maps, value chains, operating models, value streams, and business models. Currently BA is in a state of hyper-innovation. There are no rules, no best practices, and few big success stories so we all have a lot to learn here.

• Encourage the EA team, CIOs, and other IT executives to see IT as a business unit itself; creating demand management processes, product and service portfolios, and a business model of their own. The best way to understand the business world “out there” is to first understand the business “in here.”

• Spend more time with business professionals to really understand their needs. EAs have a good understanding of what IT needs from them but now we need to understand what the business needs from us.

Comments

re: Is EA About The Business Or Just IT?

I've been trying to 'DIGG' this but the URL is showing as invalid so it won't accept. Can you provide a permalink that works?

re: Is EA About The Business Or Just IT?

The above assessment by Jeff Scott is accurate to a large degree, but I have been taking a terminology-management approach to business architecture, and thus resource architecture (including IT); publicly advocating it as an EA and Enterprise Management approach since the 1980's prior to Zachman; made it visible and public in the 1990's to the DoD community prior to C4ISR and DoDAF; made it visible to the CIO Council FEAF community since 1997; and (as specified by GAO as necessary for an EA) provided a detailed full EA methodology, underlying metamodel with framework of output products, supporting-technology-specifications, implementation project plan, and operating and maintenance procedures to OMB FEA in September 2002.My reward for being this "voice in the wilderness" has been to be repeatedly blown off by the IT addicts (i.e., government authorities) and their pushers (government contractors). A tangible piece of high priced hardware or software (such as an EA tool and repository), and the expensive labor to configure it, develop for it, and operate it, are much more "real" to short-visioned executives and managers, and their willing contracted-suppliers, than "getting clarity on information meaning, information needs, and information requirements" to minimize the IT needed for full capability and capacity.If you review the Clinger-Cohen Act, which most in the US Government view as the "driver" for enterprise architecture as a means of constraining IT wildness, you'll notice something that supports my points, and which is typically overlooked by the IT-oriented CIOs. When CCA establishes the requirement for each Federal Executive Branch Agency and Bureau to have CIOs, the CIOs are first responsible for INFORMATION RESOURCE MANAGEMENT (IRM), and secondly responsible for INFORMATION TECHNOLOGY (IT). How many Federal CIO's have professional competence or interest in IRM? Not many - that's the soft realm of knowledge and meaning - ontologies and semantics, both parts of terminology management - that's librarian stuff!EA is neither about the business or about IT, it is about getting full, accurate and timely information of the enterprise content (internal parts, relationships, and attributes) and context (external environment parts, relationships, and attributes) into the hands or minds of workers, managers, executives, boards/legislatures, and owners/investors/citizens. Once you have the information organized, then business operates better and IT continues to serve its enabling and capability and capacity multiplying role (without breaking the bank).Simply - an Enterprise Architecture is a knowledge-base, built using an underlying EA metamodel which is an ontology. Anyone who says otherwise doesn't understand what they are doing - they are too deep in the IT and Data Syntax valleys to understand the view from the business hilltop or the terminology mountain - they are blind to the bigger picture. And to integrate EA knowledge-bases and ontologies, one must use a common foundational unifying (not upper) ontology that can only be built from a holistic and strategic (i.e., mountain-top) viewpoint. No other solution will address the organization's needs in the near to long term. Two decades since Zachman have shown this EA "blindness to the terminology-context" repeatedly. Subsequent to my approach, Zachman, DoD TAFIM/C4ISR/DoDAF, TOGAF, CIO Council FEAF, OMB FEA, all can only go to a certain point (the hillsides of their valley), and then they hit a wall that they cannot see over, around, or through. I'd identified this to the OMB FEA primary contractor in 2002 - and they didn't pursue it because they were happy selling snake oil to the unsuspecting and trusting clients.Even two Forrester analysts were aware of my terminology-management-based EA and methods. One was supporting an advocate, one was dismissive. The advocate saw and sought the bigger EA vision, the dismissive one catered to the buzz and not the need. The visionary advocate departed, the IT focused one remained and became more visible.The visionary Forrester analyst is now being shown to have been right - my EA approach could have since 1988, and still can, sort out and simplify the whole spectrum of EA requirements and capabilities. As I see it, the US Government has spent hundreds of billions of dollars purchasing inadequate EA services and products that could NEVER deliver what the government and commercial EA clients wanted - accurate and timely information about the enterpise as a whole, its parts, and its external environment. All they had to do to gain that capability was listen to a GS-13 in Germany who had a proven and officially-accepted approach, and then a demonstrated application, to achieve this - in 1989.What is missing from the EA camp is the understanding of information science. EA does not need programmers nearly as much as it needs terminologists - first terminology, then technology. Or alternately - first semantics, then syntax, then technology. Even the big push to SOA and services (for human to human, and human to computer communication) is acknowledged to be totally dependent upon semantic interoperability, and any semantic interoperability between two or more domains is one of the results of a shared terminology management and engineering process used by those domains. So if you want a useful SOA, do your terminology first.Both the IT and business efforts in EA are barely looking at syntax, and looking mostly at technology - finding a solution to an unspecified problem about information needs. A terminology management and engineering effort is the most effective and efficient way to get to the required information specifications within and across domains to enable semantic interoperability between persons, cultures, groups, communities, organizations, and their computers and information services.