Aligning the Enterprise Architecture (EA) with the business strategy is a critical goal of every EA initiative. Many Enterprise Architecture teams can’t demonstrate the business relevance of their EA programs. As a result, they are either irrelevant to the business success or they fail to deliver a business value. To ensure that the business value is delivered and demonstrated in the organization, Gartner has proposed a selection of best practices for enterprise architects. In the following post I want to present them to you. I hope this will help you to align your Enterprise Architecture with your business strategy.

1: Engage internal and external stakeholders

A truly aligned architecture effort requires significant input from pretty much everybody in the enterprise and its ecosystem. Getting the buy-in from internal stakeholders (e.g. line management, business operations, IT operations, support functions) and external stakeholders (e.g. service providers, outsourcers) is a critical success factor for every EA initiative. This buy-in requires engagement, so reaching out to each of these constituencies is necessary.

Engaging with a wide range of stakeholders can provide insights into the strategic drivers of the enterprise – a better-informed EA team and a “360-degree” view of the business strategy are the results.

2: Never go in with a blank sheet of paper

As every stakeholder group has a different view of the required detail level, open-ended questions are not the best idea when engaging any of the stakeholders. Because most of them are not familiar with EA deliverables, open-ended questions can make them defensive. To engage the stakeholders at the appropriate level of detail and to structure the discussion, it’s more productive to present a straw model as a basis for refinement and further development.

3: Validate, socialize, then validate again

So, what are the steps that need to be taken to align the Enterprise Architecture with the business strategy?

• Examine the business strategy and environmental trends: understand the direction of and drivers for the architecture
• Articulate the requirements, principles and models that describe the future state and the evolution of the enterprise toward that future state.
• Document the current state to identify gaps with the future state.
• Define the steps that need to be taken to achieve the future state vision.
• Guide the implementation of that road map by exercising appropriate governance over the strategic initiatives of the enterprise that are charged with improving the business’s ability to operate.

This process is highly iterative and requires collaboration with the stakeholders at every step along the way. To successfully execute this process the EA team needs strong interpersonal and communication skills.

4: Go to the business strategy, if the business strategy is not coming to you

A lot of companies don’t have an explicit business strategy. However, this doesn’t mean there is no business strategy! In many cases the enterprise is a collection of business units with different business models and therefore different strategies. A big effort is required to articulate the business strategy of an enterprise with highly autonomous units, because the specific strategies of the different units must be considered and consolidated. When formulating an integrated business strategy, common strategic objectives must be established and differences in priorities or conflicting objectives must be noted as well.

5: A less formal approach for the Common Requirements Vision (CRV) process

If your EA team encounters difficulties to persuade the company that a structured CRV process is needed, apply a less formal approach. Adopt the CRV constructs, but presents them in a less formal manner. Simply ask some questions:

• How must the business change?
• What new types of information will be required?
• What new technology capabilities must be provided?
• What programs will support our strategic objectives?

The CRV components are still the same, but the less formal structure increases the chances of acceptance. The following figure provides an example of how an informal CRV might look.

Figure found at gartner.com

6: Use the EA to inform other strategic and governance initiatives in the enterprise

Most enterprises are running different strategic initiatives at the same time. These initiatives were typically started in different parts of the organization with different objectives and different decision rights. The Enterprise Architecture should provide specific guidance to all the strategic and governance initiatives of the enterprise. Take the requirements identified in the figure above:

In this example, the strategies include attracting high-net-worth customers with excellent online capabilities and deepening the relationship with those customers to achieve greater customer profitability. These strategies will drive substantial changes in the bank’s business, including the creation of a personal banker function and the associated account management processes. There will be a need for profitability information by customer and channel, which will be provided by a customer analytics initiative supported by data warehousing and business analytics technologies.

These requirements give specific guidance to the business process competency center, which will need to design the new processes and drive the organizational changes as well as to the business intelligence competency center, which will need to focus on providing customer profitability data to business management. Such information also provides guidance to the EA team, which needs to incorporate data warehousing and business analytics technology into the bank’s enterprise architecture. There will likely be a number of projects in the bank’s portfolio that support the customer analytics program. It is the job of the program and portfolio management functions to ensure that these projects deliver the business value that is envisioned.

The Enterprise Architecture guidance principle supports the evolution of the enterprise to the desired future state.

Today I want to sum up a McKinsey Quarterly article, which describes how to reduce IT costs and complexity in 3 steps.

The IT architecture of a company can be seen as formal description of its business operations, business applications, databases as well as the equipment that run the applications. As the IT architecture is growing organically over the years, it is hard to control. In almost every established enterprise you can find duplicated systems, inconsistent data and provisional (data and application) integration. IT initiatives are often driven by short-term needs, not by a long-term blueprint.

Time to clean up this mess! Especially now, in times of the economic crises, it’s a unique opportunity to reduce IT costs and boost business agility significantly. It’s time for a clearly defined IT blueprint with organization-wide guidelines for the most appropriate and efficient systems and processes.

Business leaders must evaluate the business requirements and processes that underlie the existing architecture and then explore more efficient alternatives. For minimal disruptions and maximal benefits, the article suggests a three-phase approach.

Phase 1: Immediate Cleanup

The first phase should have a length of three to nine month. The team’s task is to generate quick wins through cost reductions by rationalizing software licenses, canceling noncompliant projects and decommissioning little- or never-used applications.

The savings in the first phase are not that high, but they are important to keep the management on track for the next steps.

Phase 2: Reducing Complexity

The second phase should have a length of six to twelve month. In this time the team decides if existing IT applications and system are really needed in future. The following methods are used to reduce complexity:

• Enforce out-of-the-box solutions
• Reuse existing components
• Consolidate databases
• Standardize technologies
• Reduce interface complexity
• Consolidate systems that do similar things

When IT and business managers analyze different opportunities, they must keep an eye on the trade-offs between short-term benefits for business units and long term costs for the entire company.

Phase 3: Business Innovation

The third phase should have a length of at least one year. In this most ambitious phase companies must consider transforming or even completely reinventing themselves. IT can play a major role in implementing big changes in the way companies run their business by supporting strategic innovation. Therefore, the IT must assess alternate operating models and shape the future with new solutions, for example using the Internet for online collaboration among employees or product innovation with help of customers and suppliers. New tools and processes can help to find profitable niches in declining markets and increase productivity.

The answer to the current economic situation is not only IT costs reduction. The answer is also IT complexity reduction, which leads to improved agility, greater flexibility, faster times to market, more efficient and effective business processes as well as faster growth once the turnaround begins.

In his article, Stephen Swoyer opens a new perspective on Cloud Computing to me. Quoting Stephen Elliot, vice-president of strategy with CA Inc.’s infrastructure management and automation practice, he figures out the importance of the cloud concept for enterprises.

For Elliot, Cloud Computing is basically a conceptual refinement of pervasive virtualization. He argues that the Enterprise Cloud model is an inevitable consequence of pervasive virtualization, a virtualization with a business-centric mindset.

Cloud Computing is is about making the IT accountable for the CIO and CEO, not about virtualizing the IT. Customers will not pay the IT to only host their applications or services. Customers purchase a clearly defined service. Therefore, the Enterprise Cloud should be seen as business-process-as-a-service, not so much as software-as-a-service.

In the business-process-as-a-service model, the value of the Enterprise Cloud can be measured with business metrics. If vendors spotlight the accountability as advantage of this model, the customers would be able to provide a proper calculation of the ROI of adapting Cloud Computing. On that condition Enterprise Clouds would become reality in organizations. As computational costs continue to move downward, the financial ROI of adapting Cloud Computing will become even better in future. It’s just a matter of time before it becomes a norm for organizations to take advantage of the Enterprise Cloud.

On Monday I blogged about the potential values of Cloud Computing. Today I want to jump straight into the same topic and enlarge the introduced model by analyzing the value of Cloud Computing from a public and a private perspective.

Public means, that the cloud offerings are owned and managed by a third party. From these remote installations others can rent capacities. The private perspective puts the focus on infrastructure that you install and own, but that implements many of the technology platform features found in large “scale-out” server farms run by public cloud providers.

Thicker lines around the value element mean, that more emphasis is placed on that element. Fainter lines mark the less important or missing value elements.

As the diagram says, strategic and economic values seem to be more important in public cloud offerings. Architectural values can be found as well, even if people do not always keep this value category in mind. In contrast, private cloud offerings are limited only to the architectural values.

From this point of view, public and private cloud offerings seem to be the complete opposite of each other. That does not mean, one is better than the other. It’s just necessary to understand the differences and benefit from that knowledge.

How can public and private cloud offerings be combined to receive the maximum value? Are there other points to be considered in the value model? What are your thoughts about cloud values? Let me know what you think!

Found at: mwdadvisors.com

I found a very useful model for the potential value of cloud computing, which distinguishes three value areas.  As the cloud aligns the time and the size of investments with the value you receive, cloud computing delivers an economic value. You don’t need to spend millions of Euros for it-infrastructure today and receive the revenue years later! The architectural value of cloud computing is the simple and abstract environment, that hides the complexity. That makes it easier and faster to develop and deploy applications. The strategic value concentrates on the organization effectiveness. It helps your organization to differentiate from others and focus on the processes that really add value to your business.

Do you think this model can be useful? Do you see any other cloud values which should be captured by the model?

Found at: Mwdadvisors.com

The Open Group, OASIS and OMG have published a concerted document about the open SOA standard landscape and the relation of the myriad of standards in this area.

In their own words the document:

[...] explains and positions architectural standards for SOA reference models and ontologies, reference architectures, maturity models, SOA modeling languages, and open standards work related to the topic of SOA governance. It also outlines the agreement on core SOA and SOA governance concepts.
This document is intended to serve as a guide to the reader to help differentiate and select specifications appropriate to their needs.

Direct link: Navigating the SOA Open Standards Landscape Around Architecture.

Some things can’t be said too often: The key skill in todays business is the provision of concise »on the point« information. Of course this doesn’t only work with coffee.

The following scribble shows an example how to display business processes along with their underlying technical counterparts (services and databases).

The diagram was used in one of my last engagements and provided a lot of information in one view:

• The business process
• The (external) services called
• Necessary middleware/adapters
• Underlying datasources

The boxes pointing to the right symbolize »callbacks« i. e. calls in an asynchronous scenario with arbitrary time between the calls. The boxes with an open left side stand for the counterpart waiting for such calls. If services couldn’t be called directly e. g. because protocol conversion had to be considered (RMI2SOAP, …) the adapter swimlane was used to show the middleware in use.

Of course the boxes were labeled with even more information but for now the general blueprint is interesting enough. Techies and Business Folks were discussing the same diagrams. Questions of data origin and synchronisatin problem could be simultaneously discussed in terms of processes and technical constraints.

Of course there are countless variations of this swimlane-like type of diagram. Any ideas? What are possible improvements? What do you use in similar contexts?