EA in the innovation era.

Now more than ever, organizations are embracing EA practices as they know it is the true answer to today’s business agility and technology disruptions. Large organizations are busy developing their EA capabilities in a manner that gives them an advantage over their competitors.

Digital business trends have created new business designs. Enterprises that are sticking to their traditional EA practices will not be able to cope in this era of digital transformation. The skillset required in this era is no longer IT focused. Organizations need to recruit and develop EA caliber that is business outcome focused and very responsive to technology innovation opportunities.

According to Gartner, world-class EA practices that can stand-up to this challenges have a wide range of stakeholders involved in the EA program. Their teams usually have a deep understanding of the strategy and are equipped with a variety of advanced team resources that enable problem solving skills.  In addition, these organizations have well-structured enterprise architecture governance that defines how the EA program is maintained and how it relates to other enterprise-wide process such as capital planning. Moreover, they do a have solid EA measurement program that is well integrated within the architectural process.

Yet, this world class EA practices needs to improve its ability to identify and understand the business economic and financial factors that is impacted by innovation. The fact that innovations are not tested technologies, requires that these organizations conduct emerging technology evaluation and determine the opportunities that can be sought to achieve certain business outcomes.

This means that the future will call for super enterprise architects who do not use the traditional ways of EA to support decision making. These super Enterprise architects will not emerge out of nowhere. In fact EA institutions needs to start preparing and developing them.

Good and Bad practices of transitioning to the future State

Lately, I was among a group of enterprise architects and IT professionals who shared their experiences and thoughts on how their organizations transition from a current state to a desired future state, in particular we discussed the use of road-maps to help the enterprise visualize the transition. Although I have blogged twice about EA road-maps, I decided to share this interesting discussion and my thoughts out of it.

It surprised me that many of them felt that the road-maps developed in their organizations are “too dense with technical information”. Loads of technical details are included such as Application Middle-ware Services, Data Services, Network Services, Network-based Services, Platform Services, Development Services, and Security Services making them rather look as technical deployment plans. Identified initiatives are not presented in a way that shows how they are related to strategy and dependent on each other. In other words, it is very difficult to get the information you need out of them. I can see that these organization had fallen into one of the worst EA practices identified by Gartner which is: confusing technology architecture with enterprise architecture.

Some professionals mentioned that their organizations do not use road-maps to guide change efforts. In these organizations, changes are identified in a reactive manner. Changes are either triggered by stakeholders or internal and external events through emails, process workflows and town hall meetings.  Well, I am confident that these organizations suffer from poor coordination and a lack of a common ground on how the enterprise should move towards its future directions. Therefore, It can be said that they do not really have an EA program in place.

Many professional stated that their organizations use graphical high level road-maps to illustrate the sequence of capabilities that need to be obtained to reach the desired future state.  Their road-maps are updated on a periodic basis to reflect the timelines and scope of initiatives that will affect the organization. According to them, these road-maps were excellent communication tools that brought the attention of even the non-executive staff.

One of the enterprise architects explained how their business outcome based enterprise architecture practice leveraged the use of road-maps to communicate their transition to the target architecture in the most effective way, by listing the outcomes and the initiatives along with disruptors and risks. This has allowed them to show what would be delivered and how these outcomes would address the disruptors and risks. I believe that this approach has allowed stakeholders outside of the enterprise architecture team to easily understand the goals of the enterprise architecture program.

There is no doubt that a simple, clear graphical EA road-maps can allow the organization to coordinate and communicate change efforts, as long as this road-map is kept current.

See you in week 15 !

Translating the strategy

Gartner defines Enterprise architecture as “the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise's future state and enable its evolution.”  We have been taught that our architecture efforts should be fully aligned with the corporate strategy and that business should be fully engaged. The question is how can we achieve this?

It all starts with understanding where your organization is heading to?  What are its explicit and implicit goals? Even if it is not well articulated, you should be able to discover and derive the strategy, in order to define the business context on which your EA work will be based.  Sources like annual reports, presentations to stockholders and senior management communications can be of great help.

You should also invest some time in trying to understand the environmental forces that affect the enterprise and the enterprise strategic responses to them. These forces can be internal such as budgetary constraints and organizational culture or external such as technology trends, competition and changes in regulations.

Stakeholders is another great source; both internal and external. You can get significant insights and inputs from stakeholders across all the levels of the enterprise from the senior executive team to the line management, the support functions and IT operations. Contractors and service providers’ perspectives should also be considered as it may shed the light on some of the strategic drivers of the enterprise.

Once you have something solid in hand to be presented, go and validate it. Engage with the stakeholders in workshops and use what you have to guide the conversations. You will probably encounter different views and colliding perspectives. Nevertheless, everything will eventually synergize as you continue to refine your work. Towards the end, everybody will agree on a set of business outcomes that must be achieved.

Now that  you have a big picture of the enterprise, its critical business issues and priorities. You can start stage planning your business outcome-focused architecture into iterations. This way, your EA program’s value to the business can be perceived, measured and appreciated.

Have a nice week!

An Enterprise Architecture Balanced Scorecard

We are approaching the digital business era where enterprise architecture (EA) has tremendous value to offer. The practice of EA has evolved over the past few years, yet, most EA programs do not have structured approach to measurement and reporting. They fail to communicate their performance and value to the enterprise.

 Some of these organizations EA is seen as a staff function that is hard to be measured. Other organizations are not very clear what to measure the EA program alignment with projects or the EA process quality and value.

According to Forrester, “A small set of contextually relevant metrics puts the EA program in the context of organization goals and outcomes”. Forrester has developed an Enterprise Architecture Balanced Scorecard (EABSC) with the following four perspectives:

• Health. Intended to measure the current fitness level of a tech management organization and the technology landscape it supports with the support of the EA practice.

• Service.  Intended to measure how EA can help the tech management in delivering services through the use of reference architectures and patterns and projects architecture review.

• Outcome. Intended to measure direct contributions to business outcomes.

• Agility. Intends to measure the EA agility and responsiveness to rapidly changing business needs architectures for technology, service, and application portfolios.

I liked the Forrester approach so much. I do agree with Forrester that there is no excuse for not measuring your program. I will certainly use this balance scorecard to select metrics to measure my EA program in the future.

Enterprise Architecture matters

Now, I can see why Enterprise architecture matters. I am super busy this week therefore I am sharing this short insights.

Back in 2006, ABC’s new CIO had a very difficult time accepting the IT road map developed two years before. One of the problematic areas was definitely that the proposed solution architectures and models were vendor specific. This was due to the fact that the consultancy firm that developed the road-map and the implementer was the same entity!  How Ironic!

We were asked to start clear and carry out enterprise wide requirement analysis exercises. Our work resulted an enterprise business model that is technology independent. We were able to carry out current state assessment and see where we fall in the maturity ladder. I do recall that this current state assessment had enable us to gain the trust of the sponsor and executive team. For the first time in our department, we were able to understand the problem before soliciting the vendors to propose solutions. 

Further to the last example of our work in ABC in 2006, the enterprise wide models developed by our team, have enabled us to identify common concepts that can be reused in different functional components. These concepts were later developed into enterprise-wide modules. This was effective in so many levels I do not need to count.

Isn't this simply great.

EA Road Maps Once again

My reflections this week continues to be on developing the EA road map. I have decided to assess a road map that was developed in my previous organization using this Gartner Article “Use Road Maps to Chart a Course to the Future-State Architecture”

Gartner identifies two types of conceptual level road maps:

•            Asset-change-focused road maps

The road map presented to our senior executive has included a model that shows how different enterprise functions, enterprise solutions and governance can be developed and leveraged at the different states of how information technology is used in the enterprise (Growing from a support role to an enabler role to a differentiator role). The transition in the state of the asset was highlighted along with its area of impact. This has enabled the leadership team to identify common transition strategies and the added value that comes with. This one single model helped build a unified mental picture that prioritizes future potential initiatives within the executive team

•            Project-timing-focused road maps

This road map also included proposed implementation approaches along with the associated timelines options for key near term projects (mainly projects in the coming 24 months). Different options were explored in a manner that is much more detailed than the Asset-change-focused model, yet it was still at the conceptual level.

Sub projects and key stages were assessed along with their dependencies. All of the options were assessed against an evaluation criteria and the recommended option was presented.

From above you can see that both road map models were used in the same presentation. Each of these models answers the “why-what-how-when'' questions from a different viewpoint.  The road map continued to be the basis on which our EA initiatives were identified.

 Two years later we considered updating the road map, only to find that it is still relevant so we decided to develop an addendum to it to include new emerging trends and consider new risks.

Why was is it still relevant two years later?!!! Well, that’s another story!

EA Road map Thoughts

I do now have a fair understanding of how a current state architecture and a future state architecture should consist of.  Next, we need to identify gaps. This is achieved by defining the linkage between current and future EA components. This way, any capability that the enterprise is lacking in order to perform at the desired level will be clearly shown. A road map should be developed to close these gaps and move to the desired future state. Let’s see how Mr. John Doe of Blog Two has handled this matter.

 “I had to learn from my previous mistake and build an EA road map that appeals to its audience. In other words, a road map that they can relate to, leverage and adopt” John Doe told me.  John has invested enough time in understanding his key stakeholders and what matters to them most. He used this understanding to define what should the road map address (scope), its depth and its focus. It is important to note that the audience of the EA Road map is any stakeholder who is involved in administering and/or implementing the EA program.

“This road map is supposed to guide investment decisions” said John Doe, “therefore, I was guided by three things, the strategy, the future state and disruptive technologies out there”  To develop a road map one should have a very broad look that goes beyond the enterprise and reach to the larger ecosystem. Big Data, Digital business and Internet of things (IOT) has started to affect a lot of industries. For example, you won’t be able to compete in the Healthcare industry soon without leveraging IOT and Big Data.

“To ensure the road map remains useful and valuable” said John Doe “I have defined business outcome metrics to assess projects and initiatives proposed in the road map”. This has helped John Doe and the enterprise schedule reviews and check on the progress of the road map.

In addition to what I have learnt from John, the road map also need to define the activities & time frames for implementing the proposed changes in business and technology in light of dependencies, priorities and constraints.

That’s all for now!

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!

EA Foundations

In the past few months; since I have started my studies in Pennsylvania State University, I have been asked several times by friends, colleagues and even relatives, what is exactly Enterprise Architecture is all about. And since those questions were asked in casual settings I had to give simple answers but I have felt I have never truly fill their curiosity.

So, I had to find a way to present EA to those who have absolutely no clue about it, in a manner that can make them appreciate its value. And what a better way to do this in our country; than highlighting the pain areas that can only be solved by establishing EA practices.

What I did is that I always started to ask the person in front of me about the strategy adopted in their organization  and whether it is really driving execution. This has almost led all of them to talk about conflicts between different business units in their organizations, and how senior management is isolated from the lower operational levels. I usually, then, introduce Enterprise Architecture, only to be asked "That's great, How does it work?!"

In my opinion, Enterprise architecture is such a complex discipline that emerged in response to the highly dynamic environment of today's business. IT no longer plays a support role, as a matter of fact it is currently seen as a differentiating factor that can add substantial value to the business.  

Implementing an Enterprise architecture is not a one time event but  an ongoing program that forever changes the way the enterprise is doing business. Many enterprise architecture frameworks exist and can be adopted to implement the EA practice in any organization to produce the following:

• An architectural view that describe the current state of the enterprise, its components and  their interrelationships.
• An architectural view that describe the desired future state of the enterprise
• An Enterprise architecture management plan that acts a a road map for the transition.

If properly governed and adopted; Enterprise architecture can facilitate and foster complete alignment between business, information and technology in such a way that serves the strategy and allows Organizations to keep up with emerging technologies and digital disruptions. 

However, Enterprises are encouraged to adopt an incremental approach to EA and focus on specific desired business outcomes to enjoy fast value realization and avoid a massive failure of the program

What do I admire most about Enterprise Architecture? The holistic view that comes with it !