Enterprise Architecture is Strictly for Business

What is architecture?

From the leaders of architecture development the definition of architecture is…

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.[1]

From the above definition it is possible to say that all software has architecture because all software has some sort of structure that is composed of interrelated elements. That’s just what software is. But just because all software has architecture doesn’t mean that all architectures are good. Quite the contrary, there are many software architectures out there that are not flexible, are not extensible, or are just plain unusable. It is when software teams exert careful thought and effort into the selection and description of appropriate structures to create software that the chances of the architecture being good are greatly increased.

How is enterprise architecture different?

There are many reasons why multiple software projects are undertaken by an organization. Maybe a university needs a registration system, and a few years later adds an email service for its students and faculty, and a then few years later decides to build an interactive website for the library. Whatever the reasons, businesses of every kind have developed software systems on top of software systems until their IT resources are as diverse and de-centralized as a flea market because every time a business need came up an isolated solution was created to solve it. Over time the organization eventually drowns in sky-high IT budgets and nightmare maintenance that prompt them to look at more efficient solutions.

One more efficient solution focuses on the organization as a whole by first developing a business model. A business model defines the purpose and mission of the organization by answering many of the following questions, why are they in business, who are they, where did they come from, who are their competitors, who are their customers, what is their product, and what are they attempting to achieve? Then and only then, are the technological solutions for the organization conceived and modeled. This is enterprise architecture.

The Business of Enterprise Architecture

Enterprise architecture is strategic. It aligns technology with the business model thereby allowing the technology to move the organization towards its immediate and future goals. As you can imagine, it takes a great deal of planning and leadership to develop enterprise architecture. Everyone on the project team will have their own ideas about how specific problems should be solved, all the way from the project manager to the deployment specialist. The bigger the team, the more ideas there will be. The brighter and more experienced the team, the more varied the ideas. Without leadership and vision, instead of architecture, it is all too easy to end up with a bunch of unrelated software solutions that may satisfy immediate business goals but do not put the organization in a strategic position for future goals.

The business of enterprise architecture relies heavily on the leadership and vision of one or more architects trained in the art and science of software architecture[2].  The architecture team develops architecture that supports the business vision, proves the architecture with a proof of concept, and promotes the architecture as they continue to analyze requirements and lead the implementation.

Develop an Architecture that Supports the Business Vision

During the first phase of a project’s life cycle, business and/or system analysts summarize the pertinent business model within the vision statement[3]. The vision statement describes in detail the business position and problem statement, the stakeholders and users, the proposed system capabilities and features, as well as the quality attributes that the system must support. The quality attributes most likely to be listed within vision statements are availability, modifiability, performance, reliability, security, testability, usability, and conceptual integrity[4].

The Business Vision

The   primary business driver of XYZ was the integration of multiple systems that   were developed over thirty years for multiple partnered organizations into one overall shared system. The immediate benefits of the integration were to eliminate redundant information and improve the timeliness of reports and revenue generation. The long-term benefits were to improve customer   relationships and facilitate the acquisition and/or dissemination of partnering organizations. The business quality attributes for XYZ were:

  • Security – stakeholders   desired to replicate the security attributes of the current systems owned by   separate organizations and separate departments. The resulting software   architecture included system level authentication and sub-system level   authorization.
  • Conceptual integrity and   modifiability – stakeholders desired to maintain the system as much as   possible with their own staff that were not architects or even experienced   developers in the target language. The resulting software architecture was   based on a strictly layered architectural pattern with very simple   communication interfaces that were easy to understand and extend.
  • Reusability – stakeholders   desired to extend the system for multiple partnering organizations and   perhaps sell as an industry standard. The resulting software architecture   facilitated a software product-line.
  • Subset ability –   stakeholders desired to develop and deploy the system in incremental phases,   both departmental and organizational. The resulting software architecture   deployed sub-systems as independently executable applications within a   distributed J2ee framework.

Early in the second phase, architects design software architecture to accomplish the capabilities, features, functional requirements, and quality attributes specified in the vision statement. Once the architecture is developed and documented, it is validated via a proof of concept.

The proof of concept is an excellent communication tool. It should be used as a celebrated milestone to communicate the business vision and the technology decisions that were made to support it to the entire team. It is easy at this point to get valuable feedback from the project stakeholders and thereby involve everyone in the decision-making process.

Proof of Concept

To demonstrate the quality attributes listed above, the implementation and deployment of several significant use cases from a subsystem were selected for the architectural proof of concept. The use cases were analyzed, designed and implemented successfully within the framework.The development team balked at first at the simplistic layered architecture and   they also complained about the lack of framework utilities for presentation and security. The architecture team made adjustments to the architecture and designs where necessary and continued to lead the implementation with confidence.

As the second life cycle phase progresses, architects oversee the continuing development efforts to ensure the integrity of the quality attributes throughout the project’s life cycle. Unlike usability and functionality attributes that may be tested and measured by QA, the architecture team must take the initiative to maintain business quality attributes such as reusability and modifiability by mapping the requirements to the architecture at the component level. For the highest level of reusability and modifiability, architects must aggressively obtain and retain comprehensive knowledge of all the components developed, i.e. what they are, where they are, what they do and how they do it. Similar knowledge of the data model is also vital to eliminate redundancy and ensure data integrity.

Map the Requirements to the Architecture

The four popular methodologies for the management of the software development life cycle listed below[5] are very similar in their approaches to requirements analysis in that some form of the functional requirements are input to the process and the output is some form of high-level design specification.

Process Methodology Input into Analysis Output from Analysis
eXtreme Programming User Stories Class, Responsibility and Collaboration (CRC) Cards
Rational Unified Process (RUP) Use Case Models Analysis Models, Use Case Realizations
Model-Driven Architecture (MDA) Computation Independent Business Model (CIBM) Platform Independent Component Model (PICM)
Zachman Framework Business Models System Models

Mapping requirements to the architecture is not a low-level activity. It does not produce a technical design. It produces a conceptual idea or model that must be further refined into design and/or code. The architecture team is responsible for leading the translation of the abstract to the concrete. They are responsible for leading the development.

In eXtreme programming, the architects are the developers!

Requirements Analysis

The software development plan for XYZ contained many iterations. The first iteration produced an entire subsystem of approximately 80 use cases. Subsequent subsystems had hundreds of use cases and were broken down into mini iterations that produced functional groups of 20 to 40 use cases each.The following process tailored from RUP was used to analyze the use cases for each iteration.

  1.   A use case model was structured to understand the purpose of the grouping and to extract common functionality.
  2.   A domain model (data view) was created to understand the data being manipulated.
  3.   A component model (logical view) was created using analysis classes according to the architectural guidelines of the reference architecture.
  4.   Scenarios   were created for the basic steps for each significant use case and behavior   was distributed to the components to accomplish the outcome. If alternate or   exception paths had architectural implications, scenarios were created for   those as well.
  5.   The models and scenarios were reviewed with the architects, designers/developers, project manager, business analysts, and QA to ensure that all functional requirements for the grouping were understood and addressed and to ensure that the proposed solutions were viable. The high-level analysis models were easy to understand by end users and developers alike and were successfully used as a communication tool to promote the architecture during analysis reviews and turnovers to the implementation team.

The aggressive nature of this iterative process enhanced the architect’s ability to obtain and retain comprehensive knowledge of the system. It continually impressed the visual representation of the component model on their mind causing them to remember details of the architecture even years after they were created.

Lead the Implementation

If the development staff is inexperienced, a design in the target language should be developed as an interim step according to design guidelines developed by the architecture team. Here, the architects’ leadership is more pragmatic. Development guidelines and targeted mentorship at regular intervals are used to proactively build up the development team.

With a well-documented architecture, design and development may actually be done in parallel by developers experienced in the modeling and target languages. They need very little guidance and the architect’s leadership is present as mentor and reviewer.

Off Shoring Design and Development

Offshore designers/developers were brought onto the project for XYX after the end of   the first iteration. The architecture team held formal meetings with the offshore team to explain the architecture as soon as they came on board. They had much experience with and appreciation of architectural development and bought into the architecture quickly and completely.After analysis models were presented to the offshore design/development team, the architects continued to lead the implementation as overseers and reviewers of the impending design and development.

Leadership is the Business Driver of Architecture

The most important aspect in the development of enterprise architecture is the development of architecture that is appropriate for the business vision because great architecture is an easy sell and the creation of great architecture gives the architects the credibility they need to lead. This reflects the a win-win situation shown in the last row of the table below that was adapted from John Maxwell’s fourteenth irrefutable law of leadership, the Law of Buy-In[6].

Architects +

Architecture =


Don’t buy in

Don’t buy in

Get another   architect

Don’t buy in

Buy in

Get another   architect

Buy in

Don’t buy in

Get another   architecture

Buy in

Buy in

Get behind the   architects

Even though 100% buy in is never completely achievable, buy in from management and buy in from the designers and developers are critical for success. Buy in from management so that the architecture team has influence over the composition of the development team. They must have authority to promote those who support the architecture and to demote or even remove those who don’t or won’t. Business and/or systems analysts should also be included in promotional activities involving the architecture, especially when requirements are being gathered iteratively. If analysts are bought into the architecture, they will be less likely to put design constraints into the specifications. Even though use case specifications should never have any architectural or design elements within them, this is one of the most common errors made by those who specify requirements.

Lastly, the architecture team must also be on one accord as strife diminishes their credibility. The architecture team therefore must be a team of ultimate professionals whom are willing to trade-off their egos and their ideas for the overall good of the project.

The Architecture Team

XYZ employed and empowered a lead technology architect who managed the technology and development aspects of the project and a business architect who managed the analysis and design. For three years, these two architects relentlessly promoted an architecture that supported the business vision for XYZ and in doing so developed business relationships that will last even longer.

[1] Software Architecture in Practice, Second Edition By Len Bass, Paul Clements, Rick Kazman

[2] Software Architecture in Practice, Second Edition By Len Bass, Paul Clements, Rick Kazman

[3] Templates and guidelines for creating vision documents are available from multiple sources.

[4] Software Architecture in Practice, Second Edition By Len Bass, Paul Clements, Rick Kazman

[5] A Practical Guide toEnterprise Architecture, McGovern, Ambler, Stevens, Linn, Sharan, and Jo

[6] The 21 Irrefutable Laws of Leadership, Maxwell


2 thoughts on “Enterprise Architecture is Strictly for Business

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s