Abstraction levels in Architecture Modeling

This week, I intend to reflect not only on my readings in this week but on elements from last week readings as well. This week will be dedicated the architecture modeling in its three abstraction levels:

• ·       Conceptual
• ·       Logical
• ·       Implementation (Physical)

Conceptual modeling of future architecture, as discussed last week, is used to simplify the complex nature of the enterprise. Conceptual Process Topologies, Conceptual Process Patterns, Conceptual Information Patterns and conceptual application architectures reflect the high level business perspective of the enterprise components, how they deliver value and how they will be used. In Zackman’s words, this is the owner’s perspective of the enterprise.

Going into much detailed modeling, comes the logical level, or what Zackman Framework calls: the designer’s perspective. Models in this level describe the systems of the organization, ensuring they fulfill the owner’s expectations. A detailed business process flow describes the “Procure to Pay” end to end business process is an example of an artifact created in this level.  An Enterprise Technical Architecture (ETA) Component catalog is another artifact in this level, it describes the general class of technology products used in the enterprise along with their associated domains, patterns and services.

Implementation Level modeling is the least abstract representation and is very detailed. In this level, specific products, software application processes and data representations are developed. The technology models of this level describe the specific technologies used to support the systems and the business in the enterprise. An example of artifacts in this level are physical data models. Models in this view reflect the Builder‘s perspective.

Aside from multiple views modeling, this week readings covered Gartner practice in developing Enterprise Technical Architecture (ETA).  The standards and guidance presented in the case is simple yet very informative to its audience.  It is grouped into a ready-to-use combinations for common solution problems.  I guess Gartner did a great job in this part.

That’s all for now, see you next week !

Build and Communicate Your Future EA architecture

No organization wants its Enterprise architecture practice to be a bunch of heavily detailed artifacts that resides in shelves and servers with no other user but the EA team. Yet, many organizations are guilty of having an enterprise architecture that yields no value to the business. There are several wrong practices of how EA is approached, presented and realized that lead to this non desired outcome.
One of these practices is giving the priority to the creation of a comprehensive current state architecture. While it is great to understand where the organization stands currently, the EA team, who follows this practice, will ultimately miss the intended alignment to business and strategy. The EA team won’t be able to keep pace with the exponentially changing technology. One of way out of this, is to adopt an EA practice that is business outcome driven. Outcome-driven EA, forces you to focus on future/target states in iterative manner. Not only this makes the EA program on top of change but directs it towards specific measurable outcomes which the business values.

Another bad practice of EA is failing to communicate to the business. When it comes the EA, the business needs answers to two main questions. One question is what will the enterprise look and function like in its future state.  Another question is, what are the specific business values that the EA delivers? The answer to the first question involves the use of conceptual modeling to simplify the complex nature of the future enterprise. This can be achieved by creating multiple views that address the concerns of stakeholders at the different levels of the enterprise.  The answer to the second question requires mapping the architectural principles to a defined set of business values. Whenever possible, measurable business outcomes should be demonstrated.

The last worst practice usually occurs when senior management has no faith on the EA program. In these organization the EA is not perceived as a management program. This probably due to the fact that EA is handled by IT and was not probably launched as a business initiative. An EA program which is not launched with strong ties to the strategy and the business should not be called an enterprise architecture program but rather an IT architecture program.

These might not be the only worst EA practices out there, but it what came to my mind after this week ‘s readings.

Understand your Enterprise Context

Among all the enterprise architecture frameworks out there, Gartner has more focus on business. Early in the EA program, Gartner's approach guides the chief architect to work closely with the business to build a common understanding of the enterprise context:

• Clear articulation and analysis of the enterprise strategy
• Analysis of the Internal & External environmental trends
• Change Requirements in Business, Information and Technology

 An anchor model : A high-level view of the future state Of the enterprise
Documenting the enterprise context enables everybody in the organization to share one single vision, on which latter Enterprise Architecture efforts can be based. A focused direction of effort means that all the changes brought by the EA program are of business value. 

In addition to this, building this common understanding of the enterprise context will engage the business leadership and thus obtaining business sponsorship.

Moreover, the enterprise context will be the perfect basis on which enterprise architecture principles can be established. These principles will be used by business IT and EA as a decision making criteria. 

Another interesting thing in Gartner's approach is that it recommends that the enterprise architecture start with the future state before the current state. Gartner considers this as one of the 10 best practices in enterprise architecture. Gartner argues that the analysis of the current state is important only in the context of gap analysis, whereas the goal of the architecture is to facilitate change to reach a desired future state. 

In my point of view, Gartner has the best practice when it comes to building an EA program that is focused on business value. Organizations using other frameworks should consider adopting this practices at an early stage in the EA program to win business support and reap some business value.

Jon Doe's EA Launching

John Doe is a sweet fellow who works in a large company in the Middle East. I am not saying that he is nice only because he agreed to share his story in this blog, but because his nice personality played an important role in this week story.

John is an experienced enterprise architect. He was hired by a company, let’s call it ABC, for the purpose of establishing an EA program. Everything looked promising to John, the company seemed mature, and the CEO is directly supporting the program. Full of confidence, John entered his first senior Executive Committee Meeting in ABC. One and half hour later, John‘s confidence started to shake.

The meeting started with a welcome message from the CEO to John. John’s competence and capabilities were praised. The CEO went on talking about the new EA program. He conveyed his ultimate support to John and demanded the same from the rest of the senior executives.  Then, John started presenting enthusiastically his carefully prepared, highly engaging slides. He presented the objectives of the EA program, its business value, typical implementation methodologies, frameworks, list of high level deliverables and etc. John enthusiasm was met with a passive aggressive response. John was really shocked. He was smart enough to realize that this only means one thing; the failure of the program!

The next few weeks john was busy doing one thing, fitting in! It was very clear to him that he is ought to understand the culture before he can move any further in the program. It wasn’t long before john sweet nature managed to gain him friends; this was stage one of his plan.

 Afterwards, John started to engage in one to one discussions with highly influential executives, most of which took place in casual settings. During these meetings, he was using the other party‘s operational context and business domain to build relevance and get him engaged. Days before the EA Charter was presented, all of the influential executives secretly received a draft copy of the charter for their review and input.

The EA launching meeting was superb. The CEO was pleased to have such an interactive session. Both Business & IT supported the EA initiatives and agreed to release all the required resources to the program. John succeeded in launching a program that is owned by the entire enterprise.

What I like about this story, is that it highlights the most critical factor that can threaten the EA program. The people factor. Even the most experienced architects, well-crafted modeling products and strict governance cannot lead to the success of the program if stakeholders buy-in and engagement is not sought.

Thank you for sharing, John Doe!