Business-focused Business architecture (^_^)

Last week, I had an interesting discussion with a colleague about Enterprise Architecture. He was particularly interested in business architecture and how it can address business challenges.

 I explained to him the transformational role of Business architecture and how it can influence product and service strategy in organizations. I went on giving examples on how Business architecture can enhance customer experience and bring synergy among business units in larger organizations.

My colleague kept asking me a question after another and then requested to see some of the artifacts so that he can “touch and feel” business architecture according to his words. I went ahead and shared with him a couple of templates from one of our case studies. He examined the artifacts thoroughly and then wondered: “Are you sure business people are able to understand and use this?”

This discussion made me realize how our abstract artifacts can end up to be fancy creations that business people cannot relate to.  This could be due to the fact that business architecture teams often seems to report to the CIO. The work products of these teams are loosely tied to the business context making it irrelevant to what’s matter to the business folks. They simply do not get it and do not care about it.

To gain real business value from Business architecture efforts, we need to:

• Understand real business needs and deliver against them: By showing the business people that you bring value, you can attract their attention to Business architecture and increase their level of understanding
• Use the right modeling and documentation methods to address business problem
• Involve the key stakeholders in the business architecture efforts. Organize workshops and allow them to co-create some of the artifacts.

In general, I do believe that focusing on meeting stakeholder needs, adopting a collaborative approach to identify the business challenges and aligning the business architecture mission to assist in addressing them is the most rewarding approach to Business architecture.

See you next week!

Thoughts on Data Stewardship

This week, my team is busy crafting down a set of models that represent the future state architecture of the HR line of business initiative. This group assignment may seem very challenging at first, but it has turned out to be an interesting activity, from which I have learnt a lot. One of the valuable lessons I have learnt from this assignment is how to approach data stewardship.

Business need to understand that quality of data is a business matter not an IT one. Business processes work on data, therefore enterprises should ensure that data quality is maintained by appointing the right subject matter expert Data Steward.

To build an architecture that delivers real business value, data stewardship rules that govern the valuation, creation, storage, use, archiving and deletion of data should be defined. Key requirements of data stewardship should be developed and mapped to the architecture Principles. This mapping reflects the integrity and consistency of the architecture. Without these governance and mapping, we will end up with an architecture that is not reliable to create business value.

I do recall a discussion with an enterprise architect about data stewardship. His company did not invest enough time and resources on data stewardship practices. Their enterprise architecture failed to achieve business related metrics. Their EA team had to fight a lot to sell the idea that business people should be in charge of data quality.

At the end, it is important to note out that data definitions should be defined in the context of the business and data governance processes should parallel processes in other business units and also it has to stay aligned with business objectives and activities. 

See you next week!

Thoughts on Enterprise Architecture Frameworks

In a previous blogs I explained how much I appreciate Gartner best practices in enterprise architecture.  Among the practices I liked are the business outcome driven EA practice that Gartner calls for. It makes sense to me that targeting one or two business outcomes at a time not only speeds up value realization but sustain the enterprise architecture program.

Saying so, I know Gartner’s framework will never be the framework of choice to any organization stepping into an enterprise architecture practice unless of course it hired Gartner consultancy services. This weekly course discussion assignment confirmed this to me.

With Gartner framework, you have a bunch of well thought practices but you are totally clueless on how your architecture is supposed to look like, and how its components relate to each other.

Nevertheless, not only Gartner Framework has problems, the open group’s TOGAF framework has its limitations as well. While the Architecture development method of TOGAF provides a step by step process to build an Architecture, business people are not attracted to it due to its inflexibility and its IT oriented approach.

It is pretty clear, that many organizations find themselves in situations were no standard Enterprise Architecture framework can fit their needs. These needs might not only be pertaining to architectural elements but some of it might be related to organizational culture or business priorities. These organizations usually go for the “best of the breed” hybrid framework that is picked and pulled from different frameworks to be relevant to their enterprise’s context and constraints.

I personally still have a crush on Gartner best practices. These practices will definitely find its way to my next enterprise architecture work assignment.

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!