Enterprise architecture myths

Shatter the enterprise architecture myths

Greta James, Research Director, Enterprise Architecture and Applications Integration, Gartner shatters a few myths related to enterprise architecture. by Soutiman Das Gupta

Why are enterprise architecture myths born?

Companies sometimes fail to observe that enterprise architecture is dynamic. Not everything in the architecture is the same after a while. New areas of business are added, new personnel are inducted, new locations are added, and new product and service lines are introduced. This has an effect on the enterprise IT infrastructure and over time gives rise to a number of architecture-related myths.

What is the most important myth of them all?

The most important myth is that companies believe that enterprise architecture is non-political. The reality is that enterprise architecture is highly political.

It's important to build enterprise architecture in a simple and layered manner. And in order to do that, it's necessary to follow a set of rules or standards. By definition, standards can restrain the choices a project can have. You can't use what you believe is the best database and best platform. You may have to use a different database and technology platform as laid down by the standards guidelines.

What usually happens is that project managers left to their own devices will not follow the enterprise standards. They would rather do things the way they did it before, and with which they are comfortable. And in these cases, the deviation from the standards may appear to cost a little less than what it would to follow the architecture standards.

Although the project costs may go down, when you look at the total lifecycle cost of the systems, you will find that it's cost-efficient to follow the standards in first place. The reason is that when you reduce the number of technologies deployed in the organization, you will consequently need less support personnel, enjoy more efficient processes, and need to rely on lesser number of different vendors.

What are some of the other myths?

Many organizations believe that enterprise architecture is an IT matter, and is of no concern to the business. In reality, enterprise architecture has significant business impacts, and so must involve the business.

The scope of the enterprise architecture is very broad and must be built in detail, so the CIO can't do it alone. It is essential to involve the heads of various business units and divisions in the architecture design, strategy, and implementation functions.

In many organizations I see that the 'C'-Level executives (CEO, CFO and the like) are not involved in making the decision. They usually delegate it to others in the organization.

Something I hear a lot is that architects only need to work in the strategic level and not worry much about the details. But of course, the devil is in the details. Things are somewhat simple at the higher levels, but when you look at the policies, standards, and guidelines it sometimes is not easy.

You need to explain the situation under which a technology must be used and how it interacts with other technologies. You need to look at the business impact of losing a location, upgrading a platform, and the number of people needed to fulfil an order.

What mistakes do companies make when they have to create an enterprise architecture?

All enterprises are big on what they want to achieve. They have mission statements and goals, which say that they want to be the biggest player in their particular fields. But they don't put much thought when they get down to lay a strategy for an enterprise architecture that will support the goals.

The strategy will actually tell them how to achieve their business and market goals. Without a strategy there will be no balance to a particular project, and companies will tend to do things in a localized way.

How must companies approach the enterprise architecture design?

The company must first identify a process. The process will include the steps to be taken in order to create the suitable architecture. There must be an architecture review, documentation of the project, and support from the top management.

Most people agree that the court system is not perfect, but it is a reasonable way to resolve a dispute. And so after the process has been identified at the start, any disputes in the project can be resolved and the expected decisions will be more palatable.

Many organizations select an architect for the enterprise architecture based on the person's technical expertise. It's a myth that an enterprise architect must only have good technology skills. In reality, architects need to have both behavioral and technical competencies in order to be successful.

To what extent should the higher management be involved in enterprise architecture?

The involvement of the higher management is needed at the time of creation of the architecture, and thereafter for governance. Its involvement is not needed on a day-to-day basis.

A sample governance architecture must be created which fits the culture of the organization. This focuses the mindset of the technical personnel and makes them sensitive to business issues. The C-level executives should make sure that the operations run in a business-friendly manner.

How much of the architecture can be outsourced?

It's a myth that enterprise architecture can be fully outsourced. And it's also not true that architecture work cannot be outsourced at all.

Selectively used, an outsourcing solution provider can provide real benefits to the architecture. Outsourcing is a strategic decision that needs to be taken after careful considerations of the benefits and trade-offs. It's however important to retain overall responsibility for the architecture.

How does a CIO avoid getting trapped in these myths?

Since the enterprise architecture is dynamic the architects need to be updated about changes and anomalies. And it's necessary that the changes are tracked and monitored in an automated manner, since the manual process is too cumbersome.

The architecture then needs to be continuously refreshed. Some technologies change very quickly like Web services, and others like databases do not change very often. These factors have to be kept in mind.

A myth depends on perceptions. So the CIO should look for evidence.

Soutiman Das Gupta can be reached at: soutimand@networkmagazineindia.com