Enterprise Architecture

.

.

.

.

 .

.

.

.

 .

.

.

.

.

.

.

.

It’s about the enterprise!

Enterprise architecture (EA) is a term with several different definitions in common use today. Some refer to their code-generating I.T. tools in their SDLC (Software Development Life Cycle) as EA. Others refer to it for business process development systems. We have found the most common use of the term being applied to IT-oriented design with touch-points to business components.

Although these are all fine definitions and supported by fine industry models, we seldom have found EA defined solely about the 30,000 foot view of the enterprise – what we call True Enterprise Architecture. That is what the MSII solution to EA, T.E.A., seeks to deliver:

Holistic representation with relevant detail of the key components that make up the enterprise.

With true enterprise architecture, it’s about the whole of the enterprise, not any one specific units agenda. Other than perhaps being the facilitators of the enterprise architecture function, which we encourage, I.T. is represented in the EA no differently than Sales, Marketing or Facilities. They are all business units with purpose in the same overall organization, relating to one and other in meaningful ways.

With true enterprise architecture you can…

• Demonstrate alignment between the business units and the overall business agenda
• Understand the relationships between all the enterprise components
• Determine the impact of change when considering change for any of the enterprise components
• Empower the business with informed decision making
• Rapidly orient resources to the structure and operation of the enterprise
• Review the purpose for the existence of enterprise components

…and so much more when you have a big picture view of all your enterprise components, their purpose, attributes, artifacts (related documents) and relationships in a single place.

EA of this nature delivers value in a multitude of ways to a variety of roles within your organization.

As we previously mentioned, this is what we at MSII consider True Enterprise Architecture and we named our EA solution after it – Acronym T.E.A.. If this is what you are looking to consider implementing at your organization, or perhaps you are looking for the business architecture aspect of other EA models like TOGAF or Zachman, you may be in the right place and we invite you to stay and learn more about our EA solution, T.E.A..

States of the Enterprise Architecture

An EA can represent the current-state of an enterprise for referencing information on how the enterprise is currently formed and operates. It can also be designed and described to represent conceptual future-states where perhaps significant change needs to be analyzed before it is made.

Having the two (or more) states of the enterprise – or a portion of it – can empower decision making in many different areas of the organization for many different factors like cost, resource requirements and the impact to quality-of-service that may result from the change. Having the before and after representations and subsequently analyzed by business analysts and other relevant resources empowers a more informed, thought out and quality decision for the change.

Generally the initial undertaking of an EA program is to capture the current-state of an enterprise. Having this alone is a tremendous value to an organization for you are serving the whole of the organization the big picture view. For example: This is especially useful for new Leadership – or any new resource for that matter – who want to examine the enterprise to see what they have and why. From enterprise policy, standards and principles to locations, agenda (mission, objectives, projects, etc.) and events (representing enterprise time – when things matter), EA is the intended single go-to place for making sense of it all.

Managing Change with Enterprise Architecture

As the previous section indicated, having an EA program can significantly help with managing change. From understanding the enterprise wide impact of potential mergers, acquisitions or compliance implementations to the implications of a small workgroups process change to the agenda of another business unit, EA can capture what is meaningful to all components of the EA and have them readily available for reference and analysis. The concept of EA at every desktop is an innovative way for you to leverage the power of this information where any resource could analyze and better understand the decisions and efforts they make at the organization.

Domains of Architecture

Several EA models reference different domains of architecture within their EA program. A domain refers to a specific area of architecture like blueprints for a facilities groups structure (or building) architectures; or visios and other documentation for an IT groups infrastructure architecture. Structure and infrastructure architecture are two different architecture domains. Enterprise architecture is a single architecture domain.

Generally these other EA models execute Technology, Application and Business Architecture.  You can see how we formed the opinion of some EA models being more IT-oriented than Enterprise-oriented. We think this is great for some purposes and addresses some short comings of IT architecture programs – now they connect to the business components. However we don’t believe this is true enterprise architecture. Perhaps it meets the de facto use of the term from the last 30+ years but not the literal insinuation of it. Again, if you are looking for a true enterprise-oriented architecture model – or the business architecture aspect of another model – than the T.E.A. solution can help.

In true enterprise architecture, it’s just enterprise (or perhaps business) architecture. All other domains of architecture have representation as a component within the enterprise, but their lower-level details are contained in their areas.

Your Enterprise Architecture Program

Nothing will empower the success of your EA efforts more than implementing a well planned program. Without it, you may being doing more of a disservice to your organization than good. Like any effective program, you will need to work out these key fundamentals:

• Governance
• Principles
• Resources
• Skills
• Marketing
• Interfacing
• Integrating
• Framework
• Methodology
• Lifecycle
• Measurements

An EA Program served from IT – which we encourage – will be expected to collaborate with all types of resources through out the enterprise and know how to get the key EA information from the collaborators – A skillset of tremendous value. More so, getting all the unstructured data out of everyone’s heads and into a structured, reference able EA repository exponentially increases the value of your program. How often have we heard that the information we need “…is in Franks head.”? Envision an EA object that Frank knows the most about. Let’s call it The Widget Refresh Business Process. Not only is the key information captured, structured and related in the enterprise architecture, but the subject matter expert for the information – Frank – is a EA resource accountable for auditing the accuracy of the information periodically to assure its integrity and accuracy. The program specifies all these types of principles to which it functions. The programs governance and integration establish the periodic audit Frank must do. This is not a required EA program method but a suggested one that will add to the value your EA program delivers.

The value is clear but…

Clearly EA has value when executed appropriately. If your organization has a complete, accurate holistic representation of the whole enterprise that can be referenced, then there is value. Exponentially so as your EA program progresses, offering future-state enterprise designs and enterprise integration (Where other units, groups and architecture domains can reference the EA objects in their processes, policies, standards, designs and the like). They key success factor is this:

• The EA must be reference-able to the organization – In other words, there must be ready access to the EA data, presented in an intuitive and meaningful manner.

You want to established desired use. This is where it is so good, users want to use it. It is the first thing that comes to mind when someone needs to know something about the architecture of the enterprise.

Whether it is the CEA him\herself, Director of HR or an apprentice analyst, serving the EA is the most important aspect to your program. It is a service after all. EA at every desktop is an ambitious yet achievable principle with the right solution, planning and marketing of your program.  The T.E.A. EA value proposition ramp demonstrates potential value progression of an EA program.

Best Served From I.T.?!.

Perhaps (We love this word). The case for serving enterprise architecture from I.T. is that I.T. possesses big data-oriented minds, holistic involvement in enterprise agenda, established relationships with most, if not all, of the enterprise business units, they are service oriented and have ready access to technology, data and tools. They are inherently empowered to execute and serve EA. This being said, they are not the only unit with such endowment and it would be fine for EA to be served from any other ambitious unit or group. The more of these previously mentioned items possessed, the better and more likely to realize success.

Next…About T.E.A.

If you like what you are reading, look for the book early 2014!