Need a Reference

Yesterday my colleagues and I were talking about Enterprise Architecture (EA) isn't just about classifying metadata but rather it is more than that. I agree that statemenr. By classifying systems, processes, data, applications, resources, technologies and other aspects of your Enterprises, we begin to understand our enterprise but it also defines a reference point from where we can understand the architecture.

Defining the reference point is key but how do we define it? Usually having some requirements that the architecture is trying to address or solve is a great place in defining your reference point. If we are trying to optimize the inputs and outputs of a system then the architecture is going to focus on the inputs and outputs of a system rather than the internals of the systems. After defining where the reference point is, we need to define the reference point. This is not a easy task since the point could a be a subsection of a system (compononet), type of of subsystem (aspect) or a combination of (collection of components or aspects). A good starting point is have your original requirements and now you look at various architecture frameworks to see if these frameworks meet some if not all of requirements. You can also create your framework by stitching together a collague of frameworks. The secret ingredient in selecting your framework is to understand if they really meet the requirements and you, as an architect, can defend your architecture.

These principles are true when you are designing a complex ontology, a metamodel or even a process. In data architecture, we can literally derive infinite relationships between data entities and attributes but in the end does your data architecture must meet the requirements and address the problems. Data relationships can jusitified in a relational database model, metamodel or a class model however all these models should compliment each other and should not contradict each other. To understand if these models are truly complimenting each other and not contradicting each other, you need to have a reference point. The reference point should address the following:

• Does the Architecture address the requirements?
• Does the Architecture capture granularity at the correct depth?
  
• Does the Architecture validate in various use cases and scenerios?

Hope this blog blurb helps you to be a better architect.

EA is doomed to fail!

Enterprise Architecture(EA) in any organization is bound to fail because it doesn't do a good job of capturing the true state of an enterprise. When people talk about EA then they talk about systems, applications, and assets within the enterprise however organization structure, an understanding of the business itself and its processes are not captured properly.

Anyway that is a quick rant!!!

Can EA ever work?

A few months ago, I was sitting with my supervisor, who is an Enterprise Architect (eArchitect), and Gartner consultants discussing on how to sell the concept of Enterprise Architecture (EA) to our organization's senior management and how to create a successful EA in our enterprise.

Before we talk about whether EA can work, lets define the term Enterprise Architecture.

the description of the current and/or future structure and behavior of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction

- Wikipedia

To capture the true essence of EA, Microsoft.com states the following about EA: "For the first time there is a methodology to encompass all of the various IT aspects and processes into a single practice.

Processes
As you can see, capturing every process and nuance in an enterprise is a daunting task. An enterprise can have mature documented processes which are known and recognized by the enterprise's resources. These processes are easy to document. There are other processes which are well known but no one has documented. There are also processes which exist but they are known by the select few. And lastly there are processes that no one is aware of but they do exist.

Resources
So who do you work for? What do you do? What projects are you working? What is your skillset? These are the typical questions an eArchitect has when he is tackling the resource view in the overall EA. The questions might be simple ones to answer however they are quite hard to ask. eArchitects don't want to invade in someone's space however they need to collect the information to complete their model and render different views of the EA to their management folks. It would be alot easier if the eArchitects went to the Enterprise's Human Resources (HR) Manager. The HR Manager might even be cooperative to share his or her information however their information might not tell the actual picture. For example, my official title in the enterprise I work for is "Computer Specialist" but my functional title is "SOA Technical Lead". Our Enterprise's HR Manager does not capture our functional titles. Therefore just going to the HR Manager and getting information from them does not give the real picture. There needs to be actual discussions between the EA team and low level managers.

Assets
What operating system is running on your operating system? Do we have licenses for this software? How come we have four versions of Microsoft Word? As you can see, assets are a big deal in an EA. Capturing assets in an EA is important since it shows an enterprise view on what, where and how did the enterprise obtain these assets. This information may be great for asset inventories however eArchitects need to make data calls with various groups to capture this information. Without understanding an enterprise's business processes, eArchitects will not be able to infer why certain assets are higher than others.

Application
eArchitects have to spend time with enterprise applications to determine if the applications are meeting some critical requirements in the enterprise. eArchitects have to work with application Subject Matter Experts (SME)s to obtain this information. (Once again eArchitects are doing a data call)

As you can see for a successful EA, eArchitects have to capture lots of information and then synthesize the information. This becomes extremely hard when other groups don't see immediate rewards in sharing their group's information. If there is no information, there is no EA and when there is no EA then the enterprise cannot be improved. For organizations to get a better view of their enterprise, they need to mandate their internal groups to share their information. If the internal groups don't share their information then the consequences are, frankly speaking, dire.

In summary, EA can work however EA will not work with extremely bright and talented eArchitects, buying the state of the art EA software nor simply creating numerous EA models. EA will work if the upper management take time and creates policy which will give power to the EA teams to capture their organizations critical information. The upper management should also investigate ways on how to automatically capture some of the EA information in their processes.