Enterprise Architecture is one of those annoying concepts. It can generally be perceived as being either too complex ( "You want to know everything to an excruciating level of detail!") Or too simple ( "It's a spreadsheet with a list of our apps on it – what's the big deal?")
The real truth about Enterprise Architecture is actually somewhere in the middle of that continuum.
Having considered this for some years, it is my experience that EA is, basically, documenting and understanding the inter-relationships between four key sets of items:
The Business processes and models
The Data and associated models
The Applications and their usages
The Technologies in use
Let's see how this would work in practice:
In any business environment, the key driver for change (and therefore the key driver for enterprise architecture) has to be Business Needs. Whether this is a new product or service line, the implementation of a new type of ERP system, the purchase of a new company, or the integration of new legal or statutory requirements, it is all a business need. This feeds into the business process architecture.
Business Process Architecture
Business Process Architecture identifies and understands the business processes that are needed to support the business needs. If you are integrating new statutory requirements it will identify which parts of your current business process will be affected by this change.If you are taking over another company you must identify and reconcile which of their existing business process overlap (or replace) your own. etc. In all cases it is paramount to understand that business process is the keystone to successful implementation of the business needs.
Data Architecture
When the business process is known and understood (or more accurately when the impact on the business process is known and understood), the underlying data that can support that business process can be identified (UML models, for example). In a well run business process design project one of the pieces of data that will be gathered relates to the need for, and use of, certain key pieces of information. For example the process may mandate that in a call centre the length of time between answering a call and finishing a call is recorded. The number of calls processed per day may be needed as well as the number of calls standing in queues waiting to be answered. If these pieces of information need to be captured then they need to be stored. Now that the data is known and understood the data architecture can define the detail behind that data.
Application Architecture
Knowing the types of data that need to be kept it is than a matter of identifying the sort of application that can manage, store and manipulate this data.
Technology Architecture
Once the application requirements are understood the underlying technology to support this can be identified. Will you be using web-based applications – in which case what technology infrastructure will you need to support that? Do the applications run on Wi-Fi hand-held devices? What is the infrastructure needed for that?
These four key facets are the basic building blocks for an enterprise architecture, and generally this is the sequence they are reviewed in and build on each other.
Tools:
I am firmly of the opinion that "If all you have is a hammer then every problem is a nail". By that I mean it is very tempting to try and use tools that you already have for things they were not totally designed to do. The same thing applies to your Enterprise Architecture. It is all too easy to look at what you currently have in your arsenal and try to apply that to the Enterprise Architecture. Sometimes this will work, sometimes it will not
Having said all this, there is a school of thought that leans towards holding all your enterprise architecture information in a single EA dedicated tool. This tool could be something like the EVA Net Modeler. The beauty of a tool such as this is that it will allow entry of information – and most importantly – reporting on that information to answer all the 'what-if' questions you may receive: "What if we decided to restrict internet access in these countries "," What if we decided to remove this approval step from our manufacturing processes? "," What if we wanted to relocate our Spanish office from Seville to Madrid ". With a well constructed and carefully maintained EA database you could quite easily identify the relevant parts of the EA to answer these questions and determine whether they would be the right thing to do.
Summary
Creating an EA is usually a fairly detailed and time consuming effort. Unfortunately this is the way with Enterprise Architecture. Start with your business need. Identify the processes needed to support that need. Identify the data needed to support that process. Identify the applications needed to support that data. Identify the technology needed to support those applications and, finally, identify the appropriate tool set to capture and manage all this information.
You do not need to go into the excruciating level of detail that you may have thought you did. Use common sense and this roadmap and your efforts should pay dividends quickly.