Enterprise Architecture and Business Analysis

Something I have struggled with in my first years of being an enterprise architect was how to align with the business analysts in our organization. I found it a lot easier to have a 30 minute meeting with the client to understand their needs than reading the entire business requirements document.

It was not until I became a business analyst myself that I realized by the time the enterprise architect gets involved in the project, the business analyst have prepared the business so that they can give you the understanding in 30 minutes. It takes weeks, if not months, of workshops with clients to get them to understand what they really need and to condense it down to a few pages of requirements. The time spent with clients during the business analysis phase of a project is never wasted time, as I always thought.

Enterprise architects should leverage, and appreciate, the business analysts in the organization. They have a specific skill in dealing with clients that most architects lack and does come in very handy during solution selection and detail design workshops. While the architect is busy positioning the solution with the architecture, the business analyst can assist with impact assessments, modelling and client relationship management.

Aligning yourself with a good business analyst makes an architect's life a lot easier.

Understanding Meta-models

I have always found it strange that at every architecture conference and meeting I have attended there was always a discussion around which meta-model to use, which one is the best, and comparing how fully populated everyone’s is. To me it is not about the meta-model, but rather the understanding, and business benefits that it brings.

An architect is someone that is supposed to understand the business, not parts of the business, but the business as a whole. An architect is supposed to see the relationships between processes and systems (Not just IT systems). In order to obtain this understanding, you must know what is important to know, and even more important, what is important to document. This in my mind is the purpose of a meta-model.

In 2006, we realized that we need an improved meta-model. We hired in some consultants to assist us to develop the meta-model. Due to the nature and time of the project only a few architects could afford their time to develop the meta-model. This lead to gaps and miss-alignment in the meta-model. We had a great picture to put on the wall but no one understood what the purpose of all the information was. Adopting a meta- model, even through a consultative process, leads to a loss of understanding and it is critical that architects understand the why more than the what.

The construction and completeness of the meta-model is determined by the questions that your business will need answers to. If your business is in the retail industry where profit margins are constrained, then you might focus more on processes and process integration than documenting detailed server specifications. On the other hand, if you are in the IT services sector, focusing on cloud computing, then the inverse might be more important. In all situations a meta-model should reflect the priorities of the business.

My recommendation to any architect starting at a company, or an architecture team building a meta-model is to obtain the understanding of the business first before attempting to create a meta-model. You will in any case start documenting the business through projects that you are involved in and in this process discover what information you need to capture and to what level of detail.

The value of a meta-model lies not in the information, but your ability to understand and put it in context to answer business questions.

Architecture Implementation

Implementing an architecture is often a very challenging process in companies. Architects know what is the right thing to do, but how to get it implemented is the challenge. The difficulty is convincing business to buy into an idea that will deliver value in the future. Building a business case that shows direct benefits is difficult enough, and convincing finance on risk alone without a user screaming for it is all but impossible.

Architects has to get their hand dirty in order to implement an architecture. The only way is to do projects, lots of projects. The point is to identify the right project, with a strong enough business case and sponsor support, to implement the architecture the business needs.

No business, unless they have very strategically focused CEO, is going to implement a business intelligence system that cost millions to do reporting, just because you say so. It requires a big enough project, with significant user requirements, and a strong business case.

In order to implement the architecture, architects first have to design, and agree, on what is the priority for implementation. The priority is based on several factors: strategic alignment, business impact, cost and architecture dependencies.

In short: design the architecture, prioritise the implementation and select the most appropriate project/s for implementation.

How to Explain Enterprise Architecture to Business

Bloemfontein, a city in South Africa, experienced water shortages a few years ago. In order to save water, the city council proposed that residents place bricks in their toilet bowls to decrease the amount of water consumed during flushes. This reduced the water consumption significantly, but impacted the overall architecture negatively. There is a standard for the amount of water that must flow through a sewerage system to keep things moving. The water flow through the sewerage system was reduced below the critical limit, and everything blocked up. Had they studied the blueprints for the sewerage system, the standards, both international and South African based, and understood the processes involved with the sewerage system, this could have been avoided.

An enterprise’s architecture is the blueprint of the business. It consists of the business processes that are executed by the employees, the information used within these processes, the applications providing the information, and the infrastructure it runs on. Enterprise Architects document the blueprint in a model known as the Enterprise Architecture Meta Model, within the context of the operating model of the business.

A good analogy for enterprise architecture is city planning. A city planner determines where the industrial, residential and business areas are within the city. They also design the water, electricity and sewerage system required for this city to function, as well as the standards for these. The city planner also determine how these utilities should be implemented as the town expands.

These are comparable to the architecture domains, standards and roadmaps. Each domain contains principles, i.e. “Residents’ safety and health will be protected in residential areas”. This principle is the reason why highways do not have off-ramps directly to your home, or why schools are built close to residential areas.

Each domain also contains the international standards that are applicable to the domain, i.e. “Roofs consisting of ceramic roof tiles must have an incline larger than 30 degrees”. The international standards provide best practices that have been determined by internationally recognized organizations. These not only protect the consumer from sub-quality items, but also enable the co-existence of multi-vendor products within the same city.

Another important component is the product standards, i.e. “Residential water supply piping must be of type P25M”. This piping protects each resident’s water supply and pressure by limiting the amount of water that each resident can draw from the system. If one resident can install a pipe larger than 25mm, he will be able to use most of the water provided for the neighborhood and adversely affect the flow of water to other residents. Each of these product standards ensure that the overall architecture is maintained.

Lastly, the roadmaps determine how the standards and products in each domain must expand and change to cater for the changes within the business, i.e. -how many, and when, shopping centers should be build to service the growth within the residential areas. Without the roadmaps, the architecture may grow out of shape, and leave only one small shopping mall for the entire city.

In general Enterprise Architecture delivers the following value to the business:

• Providing direction to IT organization via the development of the IT Strategy.
• Providing best practices and standards by documentation of the architecture, including principles, international standards, product standards and roadmaps.
• Improving the speed and quality of project delivery through standardizing the architecture development within the bigger business project delivery methodology.
• Establishing and maintaining governance through the Enterprise Architecture governance and standards.
• Providing a platform for reuse, standardization and optimization of processes, information, applications and infrastructure through the Enterprise Architecture Meta Model.
• Providing specialist knowledge and experience through consultation to all projects within IT and the business.

The Value of Enterprise Architecture

The most asked question through my various interactions with Enterprise Architects around the world is: “What does Enterprise Architects do?”. Explaining to general business people that architects develop the blueprints of the business seems only to confuse them more. The discussion usually ends up in a discussion of the toolsets. The tools used by architects are used to promote reuse and standardization.

The architecture toolset consists of methodologies (processes) and tools (documents and applications). Methodologies consist of strategy analysis and solution development processes, and tools are generally the meta-model, principles and standards.

Strategy analysis in most businesses today follows an unstructured approach, and process and solution development may have some structure, but generally is done in silos throughout the enterprise. One of the most valuable contributions of Enterprise Architecture is taking what was previously mostly guesswork and transform it into a science. Through the methodology and tools of enterprise architecture both the strategy analysis process and solution development processes are structured, delivering traceable and trackable solutions.

Strategy analysis is the architecture world does result in the same output as any other strategy development methodology, however the process which is followed deliver improved accuracy and traceability. META, which is now part of Gartner, developed the Enterprise Architecture Strategy process. This process analyzes strategy by breaking each element on the strategy into business drivers, information requirements, architecture requirements, and solutions. Each of the steps results in a traceable strategy breakdown into solutions, ensuring alignment between IT and the enterprise.

Enterprise Architecture also brings structure to the solution development process through following the architecture meta-model. A common solution development framework is achieved throughout the different business units through the meta-model. It specifies the artifacts that needs to be captured and how they relate to each other, as well as the levels and structures of the artifacts. The standardization of the development of solutions also assists the architects in their efforts to standardize, optimize and improve reuse of the overall architecture.

The meta-model focuses on what must be documented in the enterprise blueprint, following the good-enough principle. The first decision for the meta-model is what domains will be needed in terms of the architecture. These domains can follow any of the established architecture frameworks currently available in the market (Zagman, DODAF, TOGAF, TEAF, FEAF, etc.). These frameworks provide a valuable starting point for the development of the meta model, however the decision of what is critical to capture, and in what detail is independent of the framework. A study conducted by Jaap Schekkerman in 2003 showed that most companies still use internally developed frameworks, with Zagman a distant second.

Enterprise Architecture is still an evolving field and will only reach maturity in another 5-10 years, when compared to other engineering disciplines. Yet Enterprise Architecture already has a lot to offer to the business through involvement in the strategy and solution development processes.

Enterprise Architecture for IT

The term Enterprise Architect was coined by John Zachman, who developed the Zachman framework for enterprise architecture. Most enterprise architecture teams have developed from within the IT community due to the framework being developed from an IT perspective. This has lead most enterprise architecture teams to do Enterprise Architecture for IT.

The main purpose of Enterprise Architecture for IT is to enable the IT organization to better deliver services to the business. The focus is on analyzing the business strategy and requirements and enabling IT to deliver on them. This has lead to the development of the term IT Architecture, which is a more accurate description of the focus of the enterprise architecture team. It is very important to understand the difference between the focus of the two architecture efforts. In my previous blog I described what an Enterprise Architect should focus on, and will now contrast that with an IT Architect.

An IT architecture focuses on the IT organization and enabling them to support the business, not focusing on the operations of the business, or projects, but rather enabling the IT organization to be ready for business. This is done by analyzing the strategy, understanding the industry and markets and having a documented reality of the business. The gaps between these elements are translated into IT solutions that must be implemented to enable the strategy of the business. In some instances the EA team is accountable for the development and execution of the IT strategy within the company.

IT architecture is therefore a function that the IT department needs in order to satisfy the long term requirements, or strategy of business. It is the entity within the IT department that grants the CIOs a chair at the board meetings, discussing business strategies. IT architecture is the vehicle through which the IT organization becomes more flexible, predictable and value adding to the organization. It is however not the business enabler, optimizer and thought leader that will truly make it a valued partner.

There are a lot of synergies between both the Enterprise Architects and the IT Architects. Both uses similar methodologies, techniques and tools to do their daily jobs. Both analyze strategy by looking at the business from an IT point of view, document the business in a meta-model and design future states. However, EAs do this to improve the business as a whole, not just the business of IT. Enterprise Architects has a mandate to design organizational structures, assist in business strategy formulation and propose process changes in other departments. IT architects are limited to the IT organization.

There is nothing wrong with being an Enterprise Architect for IT. It reflects on the current reality in most companies, on the reality of EA today. In a few years time the Enterprise Architecture that lives in IT will move to the larger organization in more companies, changing the understanding, and development, of EA to become a value adding partner to the organization.

Enterprise Architecture as the architecture of the enterprise

What is Enterprise Architecture? Is it the collection of the business processes, information, applications and technology captured in the meta-model? Is it the list of best practises and standards that the IT organization uses? Is it the strategy analysis and resulting list of activities that the IT organization needs to execute to enable business strategy?

What I have just described is a few elements that the industry deems EA should do, therefore this is what EA is, isn't it? I believe EA is more, much more that this. In fact I believe EA needs to evolve beyond being Enterprise Architecture for IT to becoming Enterprise Architecture for the Enterprise.

This is unfortunately how most Enterprise Architecture groups are positioned. They were established by the CIO in the IT department, where the core members of the team have previously been either senior developers or system designers. The application of the methodologies of EA is limited to the IT organization, with most of the business improvements occurring on the fringes where IT and the business meet: process automation.

EA for IT is not necessarily incorrect or “bad”. It merely reflects the current sate of understanding of architecture. It adds significant business value to the organization, but from my perspective the true power of EA is the different focus and methods it can bring to the business as a whole. With IT becoming so entrenched into business’s daily operations, a business function with an IT flavour in required, as is a business function with financial, human resources, procurement, etc. experience required. All these business functions plays a part in the organization as a whole. All of these functions have a say in the strategy of the business.

According to The Open Group, Enterprise Architecture is the architecture of the enterprise. The keyword is enterprise, not the different business units, functional departments, or systems running in the organization. The focus is on how the enterprise functions, its operating model, and how to enable this.

When you look at a mining company, there may be various business units that each specializes in their own areas, e.g. the coal mining division, the platinum mining division, various processing divisions, etc. Similarly a financial company, e.g. a bank, has a credit card division, cheque division, home loans, etc. Yet, when you are an enterprise architect, the business units or divisions are not your primary concern or focus. The different divisions may be divided into the way the enterprise operates, but the focus should be one level higher, on how the enterprise functions.

Taking the mining example for instance; the enterprise focus is mine, process, sell. In the banking example could be obtain funds, manage funds, provide funds. This is the highest level of processes in the enterprise, or macro level. It reflects the enterprise, and not the business units or divisions within it necessarily.

In focussing on the enterprise, EA becomes another element in the functioning of the organization. It deals with the strategy, key programs and decisions, and impacts of business decisions within the organization as a whole. It provides another view on the organization from an IT perspective similarly to the financial function providing a financial view and the HR function providing an HR view. Forming an integral part of the organization, EA becomes more than just an enabler to the business; EA becomes a driving force within the business.