Enterprise Architecture: Technical Domains & Business Agility

In a recent posting we got to look at the importance of enterprise architectures supporting business agility. In this present posting, we'll zoom in on technical domains. As an ontology, they offer a handy way to analyze and organize architectural standards while keeping an eye on the prize: enterprise agility.

For any EA-theorists out there who skipped through that first paragraph and are shuddering at the thought of EA's focusing on solutions, I'll emphasize: This is about architectural standards relating to solutions, a core charter for enterprise architects.

Now, let's clarify what is meant by the informal term, "technical domain". As we use the term in the information technology and management arenas, here's what we mean: A technical domain is an area of IT infrastructure or practice that has elements (such as software, hardware, processes, etc) inter-related such that the focus as a whole delineates sets of contiguous complexities, expertise, investments, strengths, weaknesses, opportunities, and threats.

An excellent example is provided by the State of Virginia which has published their defined technical domain list, entitled Enterprise Technical Architecture Domains.

We have our own sub-list of Technical Domains that can assist with any focus on enterprise agility and business value:

• Enterprise Content Management
• Business Process Management
  
• Search
• Reporting
• Integration
  

I'll take a moment now and dwell on what we see is the special importance of these particular areas:
1. Each of these areas provides opportunity for implementations that greatly enhance or greatly diminish business agility.
2. Very frequently, implementations diminish enterprise agility. This frequency is so high, that study might prove that this is usually the case. Indeed, this could be a core reason for the high frequency of information management system failures, previously cited.

Let's now address some other areas are not on this sub-list.

Security and/or Identity Management
Both systems that are agile and those that are not require security and identity management. The specification and implementations of security are adequately independent of architectures segregated into business-agile-friendly and otherwise. And, as a matter of fact, security implementations in architectures that are truly business-agile-friendly can actually afford easier implementations to achieve required security.

Platform as a Service/Software as a Service
Often mentioned in discussions of agility, these areas do, of course, add differences/complexities/opportunities/etc to "normal" (on site) infrastructure architectures. Be that as it may, these areas are considered when developing standards such that the standard will be correct and applicable wherever the hosting takes place or however the hosting is distributed. That said, I'll predict here that we will see PaaS/SaaS implementations that are anti-agile and specific standards relating to these tactics will need to developed and included in enterprise architectures.


In future postings, we will be addressing each of the listed technical domains in greater depth as relates to business agility. To the extent that readers might wonder about other technical domains and why they are not included on our list focusing on business agility, your feedback and questions are welcomed and encouraged.

Enterprise Architecture: IT & Business Alignment

Enterprise Architects can drone on about the alignment that is the focus of this posting, but what does "alignment" mean? And an even more valuable question, what can be done about misalignment? In my opinion, the term "alignment" here works well because it is quite abstract. The term encompasses a spectrum of diverse opportunities that IT must seize to directly support business. At least some of these opportunities can be articulated with anecdotes from my own experience. To emphasize the breadth of the spectrum covered, I'll break down these examples into several realms:

Language
The average technologist is challenged to succinctly and clearly explain words used everyday in IT: "protocol", "service", "domain", etc. (this list goes on for pages).
One of the ways I attempt to address language issues is to regularly provide glossary handouts when I give presentations to business executives.

Priorities

• IT organizations are mandated to cut costs, and maintain or improve availability, performance, and security of IT resources.
• The priorities of the business are articulated and summarized at the highest level in the enterprise strategy.

The diversity of these two sets of priorities can define an undesireable isolation between the IT silo and the business silos: I once had an IT manager respond to a suggestion about proposing a solution to save millions of dollars for the business by saying that he was not "allowed" to give consideration to such a suggestion.

Governance
My perspective in this realm is that neither business nor IT typically appreciate the real need to establish and maintain governance for successfully managing enterprise information and leveraging IT. In such an environment, any attempt by one silo to inject information management governance into operations will likely meet resistance from other silos: another misalignment.


Now let's consider what other professionals who focus on alignment issues have to say: Macehiter Ward-Dutton is a specialist IT advisory firm which focuses exclusively on issues concerning IT-business alignment. IBM published an interesting white-paper authored by Macehiter Ward-Dutton, "The New Face of IT Service Management" which articulates both the problems that are alignment issues as well as a helpful approach to addressing those problems.

The paper starts off saying:

Our research shows that a lack of trust in IT’s ability to
deliver business value is one of the biggest hurdles that
enterprises face in bringing IT and business closer together.
In today’s business and technology environments – where
expectations of IT are higher, but where change, risk, and
complexity are increasing and the legacies of past
investments are having an ever greater impact – it’s
imperative that IT organisations find ways to demonstrate
their ability to add value.

I recommend that you read the conclusions yourself, but the quote that jumps out for me is -

The single key element that’s missing from many IT
organisations is an effective model for engaging consistently
with business teams throughout the whole lifecycle of IT
investments – from when they’re first considered, to when
systems are being managed, changed and upgraded in
operation.

In other words, "governance". And by governance here, what is meant is not just having a helpdesk and a server administrator. What is meant is having business and IT people and processes, as well as infrastructure resources that are ready, willing, and able to support the changes that are inevitable in successful business operations.

We now have the opportunity to see the inextricable connection between IT/Business alignment and IT's support for business agility.


Before ending this post, let's be clear that it is not my intention to gloss over some other interesting and provocative content in the cited white-paper-

One area is a section entitled "Architects". In that section, the author says the following-

...the outputs from architecture work typically do add incremental cost to projects, because the role of architects and architecture is to reduce the overall cost and risk of delivering a whole portfolio of IT capabilities over time, rather than minimising the cost of every individual project.

I agree with that statement, wholeheartedly, and I intend to address that situation in a later post and present a case for the necessity of considering the issue as part of generative enterprise architecture.

Other content-of-special-interest addresses Services Oriented Architecture. SOA, from the its importance to agility as well as other perspectives, will be addressed and referenced in this column at various times in the future.


Millar Consultants' Enterprise Architecture Principle relating to the alignment of Business and IT can be found here.

Enterprise Architecture: Focus on Agility

Focus on Agility - Introduction

In a previous post, I referred to the documented reality of extraordinarily high numbers of failures of Information Management systems. Scrutiny of failures, in my experience, suggests that culpability for failures often rests disproportionately with a couple of missing ingredients: lack of focus on agility and lack of business-leader sponsorship.

Are there other 'ingredients' on this list? Arguably, there are many. We can address sponsorship realities and some of the other negative influences later. This posting will lock in on agility.

An early clarification: Is the reference here to business agility or technical agility? The answer has to be, "both". As discussed at different times in this column, businesses are constantly changing. And those business changes are what can drive the changes in the information management systems.

Here's an interesting and well-thought out summary of organization agility from Rick Dove ("Enterprise Agility - What it is and what fuels it") in the UK:

In The End...

Agility is a strategic objective that must co-exist in harmony and synergy with an organization's other strategic objectives, priorities, and capabilities, whether at the enterprise level or the departmental level. It is enabled by infrastructure, business processes, and strategic policy; but in the end, it is limited by the visceral knowledge and values of change proficiency held by all involved. Agility can't be bought in a box—it must be actively practiced as a mind set. And to be effective, it must be fit to the specifics of the organizational needs and realities.

If an EA adheres to the essence of what Dove is saying, the EA must assume a global concern about agility, addressing aspects of enterprise information management that relate in a material way to the agility of the business. (Notice the appropriateness of embarking on the enterprise architecture journey only when the executive sponsorship is at the highest of [business] levels!)

Any strategic context that fosters Dove's "visceral knowledge and values of change proficiency" includes, but is not limited to, policies and procedures, training, promotions, reminder-campaigns, relevant key performance indicators, pertinent accountabilities, and relevant management behavior modelling. ( This "context" description may be reminiscent to those familiar with aspects of both Quality Improvement and successful Lean campaigns.)

Taking only a little bit of a leap now and assuming we have both a consensus about the dynamic nature of business as well as a context of operations' performers sensitized to the need for, if not the inevitability of business change, in future postings we will be narrowing our focus to individual areas of Information Management that must support business agility and addressing how we can make that support real.

Here's a sneak preview of such areas:

Important Information Management Assets
While not-necessarily-comprehensive, the following are quite universal, somewhat conceptual domains of Information Management in which business agility can rise to the level of an imperative:

Operations Automations

From CRM, to ECM, to Action Items, to Risk Management, to Supply Chain Management, to Financial Management, and beyond, enterprise applications that automate operations are deployed in every imaginable flavor (and then some).

Executive Management Information Systems

From Business Intelligence, to Business Activity Monitoring, to Action Items, to Dashboards, to Reporting, and beyond, information systems devoted to assisting executives oversee their operations are diverse and widely deployed.

Information Integration

The extraction, translation, and loading of data is not just a database phenomenon; it's enterprise-systems-wide! The all-too-common practice today has data moving from one system to another via CD's/DVD's (affectionately known as 'sneaker net'). An all-too-common solution has been Enterprise Application Integration, code words for programmers to writing complicated (hard to maintain), proprietary (unique) code connecting systems. This is a most fertile business domain for EA expertise!

Collaboration

In my judgment, social networking technology will underpin most successful business collaboration of the future. Being a relatively new domain, there is a long road ahead for can-kicking.

We will be investigating these domains in significant detail in future postings.

Ignoring Support for Business Agility: Consequences

The common paradigm in the realm of enterprise software development includes the requirements queue in which highest-ranking executive banging their fist the loudest gets the software changes first. Granted, that is the way it should be, but when the release cycles are measured in months, or goodness sakes, years, there is a predictable, insidious eventuality. Those operations folks whose requested changes are further down the queue will find another way to do their jobs. They will use CD's, spreadsheets, desktop databases, and any other tools readily available, modify their processes as needed, and proceed accordingly. As a community these folks can all-too-quickly transform as group into a formidable opposition to further support for the enterprise solution.
It has been my experience that addressing this reality can and needs to be done. There will a later posting on this subject that addresses various aspects of governance.

Millar Consultants' Enterprise Architectural Principle on Agility

...can be found here.

Enterprise Architecture Principles

A Definition

Enterprise Architecture Principles are high level statements of the fundamental values that guide Business Information Management, Information Technology (IT) decision-making and activities, and are the foundation for both business and IT architectures, standards, and policy development.

See The Open Group’s definition here.

Scope and Control

EA Principles are universally applicable to the enterprise and are typically approved by an enterprise architecture committee or review board.. Principles are sufficiently abstract, stable, and up-to-date so as to withstand technology evolving or otherwise changing, but also as to be relevant to support the enterprise business.

Restating, EA Principles are guidelines that reflect an enterprise's priorities, the business processes and other business requirements (Business Architecture), the information, data, and user applications (Information Architecture), and the Technology Architecture, which is the underlying infrastructure necessary to support the use of applications and management of data.

EA Principles are consistent with the EA Framework. (Frameworks will be discussed in a later posting.)

Declarations of EA Principles are Structured

EA Principles are formatted with a title (not required in some environments), a statement, a rationale, and implications. Though the wording for each principle title and statement typically remains constant, rationale and implications can evolve with experience and changes in the enterprise. Updates to rationale and implications can be responses to evolution of the enterprise mission, vision, and strategic plan, or to a variety of external forces.

Taxonomies of EA Principles

For convenience and clarity, EA Principles can be grouped and put into hierarchies. The Open Group, for example, in its framework, TOGAF 9, suggests that EA principles be organized into a descending hierarchy, including Enterprise Principles, IT Principles, and Architecture Principles.

Looking at another that is similar yet different, the National Institute of Health groups their EA Principles as follows:

Enterprise Principles
“Enterprise principles are applicable to all areas of the NIH Enterprise Architecture.”

- and -

Domain Principles
“Domain Principles are generally applicable to a specific area of the NIH Enterprise Architecture Framework, though some principles may be applicable to more than one area.
* Applications Principles
* Collaboration Principles
* Data Principles
* Integration Principles
* Network Principles
* Security Principles
* Systems Management Principles”

Examples of EA Principles

From the National Institute of Health:

Title: “Principal Principle” (sic)

Statement: “The NIH Enterprise Architecture applies to all aspects of NIH information technology (IT).”

Rationale: “In the NIH federated environment, a framework for information technology promotes better results.”

Implications: “This applies to all NIH systems and includes systems, data and infrastructure. EA must be followed by all NIH organizations to strengthen the ability of the NIH IT to provide a consistent and measurable level of quality to customers. An exception process will be in place to accommodate new technology and specific needs. Standards must be flexible enough to be responsive to address business needs. “

The (US federal) Government Audit Organization’s "Practical Guide to Enterprise Architecture" offers this one:

Title = Statement: Architectures facilitate change.

Rationale: In the rapidly changing IT environment, organizations need tools to manage and control their business and technical growth and change. As the technical development life cycle shortens, with new technologies replacing older systems every 18 months, organizations require an overarching architecture to capture their systems design and operating environment.

Implications: The systems developer and the chief architect should ensure the coordination between technology investments and business practices. Architectures must be used in the evaluation function of the Capital Planning and Investment Control process.

I like to think of Enterprise Architecture Principles as "The Constitution" of an organization's information management. These Principles will be amended occasionally, and lots of managerial edicts ("laws") will be passed that will come and go, but the EA Principles are the bedrock of business IM in the organization.

Millar Consultants EA Principles

This list of principles will be evolved here as the associated blog postings are published. We bring the full list to engagements as a starting point for client consideration:

Title: “Support Business Success”

Statement: “All business structures and supporting technical structures will be designed and implemented so as to support the success of the business pursuing its strategy and mission.”

Rationale: “The Enterprise mission and its strategy identify the very purpose for existence of the organization. No other agenda will be allowed equal stance.”

Implications: “In cost/benefit calculations, the business' success may, at times, force otherwise-preferred architectures to be compromised. Based on inputs from "the business", all significant present and likely future benefits to the business should be weighed and included.
Also, the implementation of both short term and long term implementations will be given greater consideration: an initial fast-reaction response to at least partially meet a new business need, followed by the sustaining architectural approach that is more cost effective in the long term.“

Title: “Support Business Agility”

Statement: “All business structures and supporting technical structures will be designed and implemented so as to support the agility of the business.”

Rationale: “Businesses must be able to change how they do business, sometimes, quickly. Architectures that support business' processes must adapt to those changes at a level that optimizes business advantage.”

Implications: “Business process changes that are subject to software update queues months-or-even-years long must be radically diminished. Solutions that offer significant possibilities of reducing updates to weeks must be considered and, as appropriate, pursued.“

Title: “Governance to Sustain Alignment”

Statement: “In order to achieve sustained alignment between business and IT, a governance practice is to be maintained. This practice includes both business and IT personnel, as well as agreed processes, and be sponsored by business operations executives. Alignment is quantified using Key Performance Indicators, with verified accountability and corrective actions. This governance is ongoing, indefinitely.”

Rationale: “To maintain continuous improvement of the business, and address inevitable business change, this governance must be created to oversee and continuously maintain alignment of IT support and information management with business operations.”

Implications: “To establish this alignment support infrastructure, adjustments in perspectives of the both business and IT executives may be required, new roles and accountabilities in both business and IT will have to be established, and migrations to update major IT architectures may have to be planned and executed.“

Title: “Business Processes”

Statement: “Manipulations and tranformations of data in the enterprise that are the enterprise's business processes should be primarily located in the 'business layer' of enterprise architecture with features, such as non-technical business administration, that support agility.”

Rationale: “The logic and other details of business processes, in which data is manipulated and transformed, can be implemented in a number of places in any enterprise architecture, including ETL facilities, Portals, ESBs, servlets, and other places.  This principle declares that in order to support both business agility and enterprise resource reusability, all such logic and other related details will be located in an environment such as a business process management system primarily under the control of the stake-holding business organization(s).  This principle facilitates the rapid change of business processes by putting the greatest amount of authority and dependency for process changes uniquely in the hands of the business silo(s).”

Implications: “The underlying IT infrastructure for this context can be considered a platform onto which there will be an IT focus on standardized integrations, security, performance, availability, extensibility, and other dimensions needed to support optimized usefulness of the BPMS by the business silo(s).“

Millar Consultants Domain Principles - Applications
Application Architecture Principles are subordinate to EA principles and are separated out so as to more easily target the correct enterprise demographic including functional silos such as business analysts and business application developers.  

Title: “Browsers are preferable to 'thick client' user interfaces”

Statement: “Web browsers are considered preferred for hosting client - side application user interfaces.”

Rationale: “Most packaged applications are being released in 2010 with web user interfaces, that is, browser access.  New, proprietary applications should be planned to have a browser-client.  Web technology in 2010 supports rich interfaces which all but equal, and at times surpass, the user experience that was unique to thick clients years ago.  The web interface by default provides the user with a familiar client-side context, and supports maximizing user acceptance while minimizing training and maintenance.”

Implications: “The design of the user interface must conform to web interface best practices.“

Title: “Application Embedded Technical Domain Capabilities”

Statement: “Applications that include bundled technical domains such as search, reporting, and integration tend to provide such functionalities as limited capabilities and should be discouraged.”

Rationale: “Examples:  The search engine available in a CRM package is not as useful to the enterprise as an enterprise search engine.  The integration available in a portal package tends to be proprietary, less useful, and significantly less strategic than corporate standards for integration based on open source.”

Implications: “Enterprises must face up to having a suite of generic resources that sufficiently meet the enterprise requirements for technical domain capabilities.“

The Enterprise Architecture Journey

Semantics. They can be wonderful!

Let's talk about the semantics of the word used often in EA: "roadmap".

A point view has evolved about the journey that is enterprise architecture. In summary:

• The existing architectural blueprint is established
• The targeted state architectural blueprint is documented
• The roadmap to get from the present to the targeted is established

A summary like this is easy enough, and often repeated. (Quibbles are invited. But I happen to particularly like this version.)

Now let's look at this 'journey' more closely-
Establishing the blueprint of the present state requires documenting the business strategy, the business activities, and the information management (IM) resources that support each activity. If there is a presumption that these descriptions represent only the static, there is misunderstanding. Indeed, to the extent that there are governance processes embedded with constant improvement, business dynamics are being included this properly documented architecture. These dynamics may or may not include elementary information management governance that will be completed by the enterprise architecture effort.

For this context, the definition of "IM governance" will be -
Processes exercised against standards and agreed procedures by individuals with authority and accountability toward supporting the manifestation of an identified business strategy by enhancing information management. Wikipedia has a more comprehensive perspective on the closely related topic of IT Governance.

For this context, the definition of "information management" will be the-

• Collection
• Organization
• Control
• Processing
• Delivery

-of business information. (See a fuller definition in Wikipedia.)

Establishing the blueprint of the targeted state requires transforming the present state documentation to reflect a new, targeted state that manifests the business strategy. The targeted state will, expectedly, reflect the some fuller measure of the governance.

Now, we have established a context for more fully considering the "road-map":
We are starting with a business environment that has early governance, if any. We must realize a newer environment that has an advanced governance dynamic. The road-map must not only guide establishment of the new processes that will be put in place to support the business strategy, but will guide the methods and timing of establishing the supporting resources such as software and infrastructure. We now have an opportunity to more easily understand how that road-map contains the pioneering efforts to manifest the expanded governance.

Let's be a little more specific so that these concepts can be that much more generative:
Governance-related activities will take place during post-targeted-state operations-
Standing board(s) of individuals with authority and accountability convene as necessary to set expectations, grant power, and verify compliance with procedures and standards.
But these same activities must be initiated during the "roadmap" -phase. Without attempting to be comprehensive, let's throw around some activities that distinguish the roadmap phase dynamic from the operations phase.

• Identification of governance board members
• Establishment of governance procedures
• Identification of preliminary standards for information management
• Establishment of procedures for constantly improving governance (cheaper, more effective, etc)
  
• Performance of project management

The "roadmap" in the EA world is a conglomeration of multi-dimensional activities that precede and establish targeted state operations.

The Imperative of Enterprise Architecture

Business must be agile and it must waste as little money as practical.

Competitors appear. Regulations get imposed. CEO's (and others in charge) come and go. Mergers happen. And the list of forces causing business to change goes on and on.

"Changing the business" can be a paraphrase for "changing the business' processes". But what if the processes of that business have been automated? (Hopefully so. And, more and more, they will be.) Ok, so now the business is changing (as always). Therefore, so must the information management (IM) systems change. That's when the "business" folks call the IT folks and say "change...". Sooner or later, the IT organization comes back with their answer. Likely, that answer is something like "8 months", "2 years", or "it can't be done".

Now, let's look at a couple of familiar reactions by the business silo:

First reaction

A typical business response to that kind of an IT answer: "Forget about it. We'll use spreadsheets, Powerpoint, and CDs. We're going to make this work and get this done!"

This reaction of the business is good, expected, and even necessary in the short term as that response addresses business' most critical issues related to time. But as this response ages without further action, the consequences are likely to be information mis-management, a deterioration of efficient collaboration within operations, and an upward trend of inefficiencies and overall costs, among other negative impacts.

Reaction 1 - the missed opportunity?

Having a longer term plan so that the future state of the organization is one of efficiently managing its information.


Second reaction

Another typical reaction by business: "George, at ABC company, uses this app that gets it done and the app costs only $15,000."
Good idea? Well, maybe. But often there is no one in either the business or IT silos asking all the questions needed to affirm the soundness of such an asset investment.

Reaction 2 - the missed opportunities?

• Knowing the greater context of present operations, as a whole...
• (...and possibly more importantly) Knowing the greater context of the targeted state for future information management, so as to be able to consider the relevant 'big picture'
  
• Having standards in place, including an information management roadmap, to measure the appropriateness of any proposed solution even as the environment is changing
• Having an information management system governance in place so that major procurements get sufficient scrutiny
  

(Realize that these bullets do not necessarily exclude bringing in ABC-company's solution; that tactic might very well fit in nicely with the roadmap as the company moves toward the targeted IM state.)


Are these reactions' "missed opportunities" real? Is there anything here worth further consideration? Unfortunately, yes.


As the result of very many 'missed opportunities' (many more than we've suggested, so far), the ugly truth is that most major information management systems fail. (See any of the annual Chaos Reports by the Standish Group.) There are many information management systems ranging in cost up into the $millions whose full lifecycles have been unexpectedly and unacceptably short (worst case, the lifecycle span is "zero" because the app is never used). Not many businesses can be unconcerned about wasting asset investment money.

It is evolving that for sufficiently large and complex systems, Enterprise Architecture stands alone offering an approach to mitigate these failures.

Only be concerned about the possibility of wasting a business investment in a system if there is any likelihood that the following would be asked: who sponsored this system and do they remain convinced that the system was a good investment?

-Millar Consultants, LLC

Risks abound, however, that any given EA activity will fail. There are many reasons for EA failures (and we will not shy away from those risks here). As stated at the launch of this blog, it is an explicit goal of this column to understand the nature of EA.

It is in this context that I now suggest that a specific, strategic goal of EA is to stem the tide of information management system failures. Accordingly, I am advocating that there is an Enterprise Architecture Imperative which is the ultimate strategic enterprise architecture principle.

"It's all about the business: support its successes."

This imperative defines at the summary level the comprehensive environment for planning and decision-making.

(Enterprise Architecture principles in general, which I distinguish as 'tactical', can be at least a little sacred to EAs and will be discussed in detail in a later posting.)

Some might be thinking: "Isn't this obvious?". Unfortunately, I am finding that these words probably need to be elevated to a loftier status of "imperative" and iterated as on-going reminders. The number of entities losing site of this forest (the overall good of the enterprise) for the all the trees (elements of the practice of architecture: tools, frameworks, principles, artifacts, etc., etc.) seems to be rising.


EAs have the opportunity, if not the obligation, to look at the larger business environment and maintain an overall, business-driven strategic goal. My opinion is that capable EAs seize that opportunity. When they do, the stage is set for everyone to benefit.

Defining Enterprise Architecture

Honestly, I think this is a topic fertile enough with material for an entire book. My approach in this posting will be to offer several attributed definitions with the aim of converging on something useful, all the while facilitating reader reactions such as:
“I see why they say it that way”, or
“Doesn’t seem as good as that other one I remember”, or
“Wow, that one’s different!”

Reactions such as “that’s the right one”, etc, are discouraged.

As a further prelude, the focus of this posting is on “Enterprise Architecture”, establishing a reference for future discussions on “Generative Enterprise Architecture”. (In my view, GEA is a subset of EA.)

Wikipedia’s definition of EA is a good place to start:

"Enterprise architecture is the science of designing an enterprise in order to rationalize its processes and organisation." [sic]

If one reads the whole definition displayed in Wikipedia, a valuable perspective emerges re: the depth and breadth of this subject. So why not stop here? End of discussion, right?

Maybe not. First of all, this approach while informative, is not succinct. If it's not succinct, potential sponsors may not pay attention.

Secondly, this mass of information contains various points that are highly debatable, and debate can fog clear understanding.

One example…

"The primary purpose of describing the architecture of an enterprise is to improve the effectiveness or efficiency of the business itself."

Point well made, but here’s just a couple of areas for lots of further discussion...
- Business agility: understanding the big picture is necessary to build an agile enterprise and support rapid change.
- Alignment between business and IT: having a design of the enterprise expressed in enterprise terms might be the major medium for concretely bridging this infamous gap.

…and another…

"Enterprise architecture has become a key component of the information technology governance process in many organizations."

Another point well made, but also subject to other considerations; such as...
- Some consider the opposite to be also true. That is, IT governance is a component of Enterprise Architecture. Which way you think about these things could impact the construction of a roadmap, and ultimately, the success of a project related to the architecture.


Let’s branch out a bit and consider blogger Loraine Lawson's interview with The Open Group’s COO, Steve Nunn. Nunn said

"As we see it, enterprise architecture is an overarching term that covers the work that is done in an organization to align IT with business goals and needs. And to me, that covers a lot of other areas. Whether or not enterprise architecture becomes the term everyone uses for what we're talking about is still potentially out for debate. I think people are talking a lot about the difference between enterprise architecture and IT architecture, and solutions architecture and data architecture, and all the others we've heard. We don't purport to be able to tell people this is the term we have to use. That's something we rely on our membership to do and the industry at large. But that's the one we're operating with at the moment in the Open Group. We see it as a role that's different and in a way unifies any of the other architect disciplines you might get in an enterprise and pulls them together."

Nunn’s words add mass to the more global (some would say, critically important) perspective of EA, as well as underlining the title’s tenuous-ness as something having a black/white definition.

A simpler, provocative definition comes from Samuel B. Holcman of the Zachman Institute for Framework Advancement:

"Enterprise Architecture is about understanding the Enterprise through
- a set of independent and non-redundant artifacts
- the interrelationships between these artifacts, and
- communicating these understandings to the numerous people that make up the enterprise"

Interesting stuff, eh?

To round out our potpourri of definitions, consider this one -

SearchCIO.com's definition of EA is

An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.

I like this last one and will be referring to it in future postings.

This last definition is -
1. Succinct
2. Consistent with the spirit and intent of other definitions
3. Encompassing and supporting the variability of discussion engendered by the breadth of EA

The exact definition of EA can be a matter of opinion. Of those definitions cited here, there are several characteristics, some implied, that are noteworthy -
1. EA is very much about the business and the business' processes.
2. EA has a primary context: the business' strategy.
3. Technology can support EA, just as it can support the business.