Greetings and Salutations,I recently attended The Enterprise Architecture Conference 2005 held by BTELL at Star Casino in Sydney. A lot of information was covered in a short amount of time (no surprise there!) and I decided that I will enter a retrospective set of entries for each of the sessions I attended. Where allowable by copyright, I’ll enter as much information as possible. Otherwise, I’ll just provide a brief description of my impressions of the session.
Demystifying Enterprise Architecture to your Organization
Presented by Sam Holcman, President, Zachman Institute for Framework Advancement.Sam presented an interesting discussion on defining and demonstrating what Enterprise Architecture is. Starting off by talking about the three ways to change a physical object being:
- GO FOR IT
This being a common approach that many use – especially in the IT industry. We’ve all seen it, the System Administrator simply modifying the configuration or the programmer making a code change. This methodology presents itself as a High Risk venture, offers Low Reliability and is oft characterized by changes of Trial and Error.
- THROW IT AWAY AND START OVER
Another common approach witnessed in our industry. Let’s not investigate whether the requirements only require a base change or minor configuration. Let’s not change the system, instead, Scrap the current system and claim that the useful life is exhausted.
- REVERSE ENGINEER THEN CHANGE IT
The least common methodology witnessed, this requires us to find and (re)examine or even (re)create the drawings/plans, change the drawings to suit the requirements and then change the object in question.
The point that Sam made was valid. The three methodologies specified are also the same three methodologies utilized to change an enterprise.
So what is Enterprise Architecture? The phrase was defined by breaking down the term and defining each section:
Architecture: is the art and science of building, and the manner in which components and artefacts are organized.
Enterprise: a collection of “organizations”/”people” related things that has a common set of goals/principles and/or a single bottom line. Thus within this definition, a whole corporation, a division, an entire group or even a single department can be considered the enterprise.
Thus Enterprise Architecture is the art and science of building a series of artefacts that are understood by a number of people that describe the area under analysis. The full definition utilized by Sam in his presentation was:
Enterprise Architecture is about understanding the Enterprise through the different artefacts, and the interrelations between these artefacts, and communicating with numerous people, that make up the Enterprise.
Artefacts can be anything that is utilised for this purpose such as: strategies, business drivers, principles, stakeholders, units, locations, budgets, functions, processes, services, information, communications, applications, systems, infrastructure, etc.
Basically, artefacts are anything that define all the areas of:
- What – Things/data
- How – Process/Functions
- Where – Locations/Networks
- Who – People/Organisations
- When – Events/Times
- Why – Goals/Motivations
So, that’s all well and good, but how do we sell this concept to our organisation? As mentioned before, there are three methodologies that are generally utilised, but the only one that offers any true value is the third.
However, even the third methodology can fail due to the fact that it may not exhibit the essence of a sustainable architecture, such as:
The value proposition for Enterprise Architecture lies in the following elements:
- The implemented enterprise reflects the intent of the “owners”
- The data means the same thing to everyone
- Messages are successfully (and consistently) transmitted from node to node
- Everyone understands the objectives/strategies
- Independent variables – Baselines for managing change
In conclusion, the value proposition of the enterprise architecture framework lies in providing:
- Cost reduction (via standardisation and reuse)
- Agility (persistent and standardised models)
- Speed (knowledge access)
- Ability to manage Virtual (out-sourced) IT
- Professionalism of staff
- De-coupling of knowledge from individuals (cope with the volatility of staff)
- Governance mechanism for critical assets
- Context for architecture education and assessment
- Adaptive mechanism to promote alignment between IT assets and business initiatives.
Sam provided a more in-depth analysis via his one day “Enterprise Architecture Planning” Seminar. If you ever get a chance to go to a Zachman presentation by Sam (or John Zachman himself) I highly recommend it.