Chapter 8 – “Architecture”

by John Dick, Holly Simmons, Maureen Vavra, Steve Zoppi

John Dick, Holly Simmons, Maureen Vavra, Steve Zoppi provide the following anecdote to describe the CIO’s architectural reality today…

Joe Marketing VP: “Hi, Bob. Just wanted to let you know that our Sales and Marketing division has purchased the XYZ CRM solution to fulfill our strategic goals for this coming year. I wanted to set up some time with you to discuss how we get our software set up for our marketing and sales folks. Do you have some time tomorrow?”

Bob CIO: “I am concerned that I was not included in the decision to purchase this software. There are many things to consider with respect to our architecture and we need to understand what is required to implement and support the product. What are you planning to use this software for?

Joe Marketing VP: “Oh, you know, CRM stuff. This is the best package on the market today. I’m sure you’ll be able to get it working easily.

Bob CIO: “Joe, were requirements written up for this? Was a technical review of the software performed?”

Joe Marketing VP: “Requirements? We had several demos and decided that this product would best meet our needs. The XYZ salesperson can hook you up with some techie guys from their company. I’ll get you the contact information.

In the chapter the authors provide an introduction to the enterprise architecture and discuss:

  • The practical steps necessary to create an architecture strategy;
  • How to avoid the pitfalls frequently associated with architectural planning and implementation;
  • Why it is important to invest time up front in defining a successful architecture to avoid frustration and expense later in the process;
  • Why architectures should not be developed as a pure product development engineer might; and
  • Why it is important to focus the architecture on customers, users and the processes that enable their success.

Are We Having Fun Yet?

Being a CIO in today’s environment is a tough job. Vendors target marketing, sales, and customer support executives in companies to sell their enterprise solutions, frequently resulting in a sale without any involvement from the IT organization. In their attempt to keep the sales cycle short, vendors are happy to avoid the difficult, technical questions raised as part of a product evaluation. Unfortunately, the business users do not typically understand the potential architecture, implementation and support issues, and do not ask all of the pertinent questions, thus resulting in a decision based on only a fraction of the necessary information. What is most difficult is that the CIO is the one left holding the bag when this happens, taking responsibility for making the solution work. Vendors enjoy lauding their product as straightforward to implement, easy to integrate, and simple to support. They even make claims that their product solves your enterprise architecture problems for you, but the reality is that these products are simply a point solution with an enterprise architecture smoke screen. The CIO and the IT organization must expend a great deal of effort figuring out how to make it all work harmoniously together.

A CIO career is truly not for the faint of heart. Architectural challenges are at every corner with varying standards, technology, integrity, and scalability that can leave you with a hodge-podge of incompatible equipment, software, and data. But this is part of the challenge and opportunity for a CIO! You and your team have the opportunity to identify what works, what does not work, and there is always a great deal of change and variety in the technologies and available solutions. You are getting paid to play with new technology and solve interesting, although difficult, architecture problems. Appreciate the challenges and rewards ahead of you!

Overview

Our focus in this chapter is to provide you, the CIO or technology manager, with a “walking tour” of enterprise architecture. The intention is not to provide a detailed reference manual for implementing an enterprise architecture strategy, but instead to offer an introduction to enterprise architecture, a practical outline of the steps necessary to create an architecture strategy, and how to avoid the pitfalls frequently associated with architectural planning and implementation. Whenever possible, references to other sources of helpful information have been included.

What is Enterprise Architecture? We define “enterprise architecture” or “target architecture” as the framework that encompasses your corporate data, network, infrastructure, security, and applications, providing a foundation to support the business needs, processes, and information.

While traditional definitions of the term “architecture” focus on the design and building of structures, this same concept can be applied to enterprise architecture. When building a house, your foundation must be built with care since every other component of the house relies on it. Your enterprise architecture is your foundation requiring stability and flexibility only gained through careful planning and design. Similarly, a shoddy house foundation can result in a structure that is unstable, unable to be expanded or added on to, and in many cases, unfit for living. The same is true for poor enterprise architecture. Careful planning that incorporates needs for future growth or changes allows your organization to avoid costly replacement or being left with an inflexible, inefficient, high maintenance foundation.

As a CIO, planning your architecture ensures future viability, a solid return on your technology investment, as well as job security. It allows you to minimize downtime, eliminate technical incompatibilities, and enforce smooth operations. It also assists you in controlling your staffing plan and costs.

When it comes to planning your technology architecture, the “pay now or pay later” principle applies. Invest your time up front in defining a successful architecture to avoid frustration and expense later in the process.

The Classic Architecture Approach

We will discuss various ways to develop and maintain your IT architecture in this chapter. Most organizations use a formal method to do the initial development and do significant updates 2-3 times a year. The underlying persistent blueprints, standards and procedures must be assigned owners and updated as needed, and published widely so that internal resources as well as vendors are aware of them.

In an area such as architecture, it is essential to build a foundation of organizational understanding regarding the need for standards. This may be a real challenge in a shop that is heavily into departmental computing. To do this you may need to establish or re-verify principles for major internal IT processes – articulate why you need a formal architecture and do this in a group setting so that key technical leaders in your organization (and any others which impact your environment) buy in. Beyond that, policies – definition and decree of your key ones - are the true infrastructure for architecture and should represent what your organization believes is needed and is willing to live by and enforce. They are particularly critical in the data and security area, as they set the proper foundation for everything else.

In general, the classic approach requires that you start with an end state vision statement of what your organization wants to put into place for architecture. These frameworks can be “borrowed” from various sources, but should be tailored to you own needs. It’s all about explicitly stating that your future direction is a layered, component oriented model, based upon industry standards whenever possible, rules and API orientated, and as open as possible. You ultimately will be developing a Target Architecture based upon business need, assessing your current state against that target, and building a migration plan to get there.

Most classic approaches today rely on a formal system, such as the Zachman framework, Whitemarsh Knowledge Worker Framework, and various tools or methods. The idea is to create a common model at the business level, and cascade top-down down to specific layer definition and the accompanying standards to support these.

The Zachman Framework, discussed further in the Planning chapter, [picture] was created John Zachman in the late 1980’s; he was a senior engineer at IBM at the time and created this model, which has stood the test of time. It is intended to straightforwardly depict an Enterprise model for an organization. It shows the designs or documents that represent the intersection between the roles in the system design process, that is, owner, designer and builder, and the product definitions, that is, what (material) it is made of, how (process) it works and where (geography or network) the components are relative to one another. It is a very useful logical tool to help understand the extent to which your Enterprise is made up of multiple subsystems that interconnect.


Whatever models or methods you choose, your organization must have models, tools and supporting processes to view individual IT projects, efforts in an Enterprise wide manner to ensure integration of:

Critical data;

Key applications;

Enforcement of corporate policies – security, controls, data privacy;

Common service levels;

Unified user/interface to facilitate intuitive use of systems; and

Viable product development if that’s what you do.

Enterprise Architecture Overview

This diagram provides an overall view the relationships of an enterprise architecture. To consider an architecture apart from its business context is to miss the point of what you as the CIO are trying to accomplish. The goal is to focus your architecture on accomplishing a business objective. You are generally not developing this architecture as a pure product development engineer might, but are rather driven by an enterprise business need generated by a requirement to sell product through a business channel that includes sales, marketing, finance, customer service, operations and product delivery, and human resources functions. The actions of these groups will result in a revenue flow and profitability calculation for the company.

For that reason your architecture is a melding of business channel considerations, which generate a set of business rules that create a functional roadmap, by which the delivery and support functions of your enterprise provide value through products or services. These business rules then drive a set of physical technical elements, which actually operate the technology component of your company’s product or services delivery, support, and accounting processes.

The channels portion is the key starting point of your architectural quest. Here is the recognition of what your company’s actual delivery proposition to the market is. This section is not focused on internal functional organizations as a traditional approach might dictate, but rather focuses on the ways product or services are delivered and those transactions communicated to your customers and eventually your internal enterprise processes. The focus of your architecture therefore becomes not your finance, engineering, or manufacturing organizations, but rather your customers and the processes that directly support their success.

Once your channels and general information delivery requirements are identified, the business rules or functional roadmap portion of your architecture can begin to take form. Many information technology organizations start with this phase by focusing on functional organizations not business channels, and are therefore distracted from the true value they can deliver by the “requirements” of a functional organization which are important and certainly relevant to that organization and possibly the enterprise, but may be business processes that do not truly support the channels they think they support, but rather add potentially administrative overhead to your enterprise. This overhead may not be truly part of the essential channel delivery function and therefore is probably not as valuable a target for technology investment or return on investment (ROI). By maintaining focus on your key channels you can determine key functional business rules and processes which deliver value to your customer, but yet still allow for proper accounting of their transactions with a minimal amount of overhead. Yes, this does mean that some functions may be better not assisted by expensive technology, but isn’t that appropriate?

After you have identified your key channels and derived from that your key business rules and developed a functional roadmap, you are ready to start addressing the technical elements that constitute the heart of your enterprise architecture.

Necessarily this starts with your network infrastructure. In today’s world the internet and associated web technologies create the window into your enterprise certainly for customers and even for internal users of your systems. Therefore, Internet, intranet, extranet, and browser-driven access to your information systems have more recently dominated the focus for your network infrastructure.

Also integral to creating this window is the architectural component that deals with the navigation and data access element of your architecture. This layer which is intimately connected with your fundamental network structure and feeds into your business rules and functional roadmap processes culminates into a controlled look, feel, and access into your applications and database architectural layers.

The final layers of your technical architecture are the heart of the business rules/logic and implementation of your functional roadmap, the applications and databases direct, store, and manage the specific functions of your business. Based on channels, business rules, and business processes these technologies whether custom developed or purchased vendor solutions form the heart of your systems. Integral to these layers, but architecturally separate are the enterprise application integration (EAI) components and inter-enterprise components, which provide the pathways that allow disparate applications and databases to interact enabling the channels and functional roadmap.

In the next few sections we will spend more time looking at each of these layers.

Planning for an Enterprise Architecture

Enterprise architecture may not be the most obvious contribution provided by the IT organization, but it is integrated into many aspects of the business. As a CIO, you must be aware and able to plan for these interdependencies when budgeting, resourcing, calculating your return on investment, or even as part of your daily operations and internal processes.

Aligning IT with the Business

While IT is a support organization, IT also has a very strategic role in defining and driving technology decisions to support the business. This definition cannot be performed by IT in a vacuum, but instead should flow directly from the corporate goals or objectives.

Assuming the executive team is defining the direction and needs for the company, and each business unit is interpreting what that means to their organization in fulfilling the objectives, it is the CIO’s responsibility to plan for sustaining systems support, focus on strategic IT needs such as infrastructure growth or systems to improve efficiencies. In addition, the CIO drives the translation of the business needs into technology needs, providing a “check and balance” to the business units in an organization, helping to avoid investment in technology that may become “shelfware”, never implemented, or even worse, implemented, but not used. Also as part of this analysis process, IT must also define what architecture changes or additions are required. This is imperative in determining the current and future architecture plan as well as determining budget and staffing requirements.

As discussed in the strategic planning chapter, aligning the architecture with business strategy and processes is essential. The obvious follow-up to this is that every major business change must initiate a re-examination of your IT architecture for impact, and the more formal the better.

The key is to ensure that all the vertical processes on the right side of the chart include architecture in some form or another. The Migration Planning should be a direct result of establishing your target architecture, the Project Portfolio should be managed by (and have a project methodology that) supports it, and the Change and Configuration Management processes must incorporate architectural planning at the logical and implementation level.

Ongoing, whatever architectural models and associated processes you adopt in IT, they will only have value if they keep that link to the business. To have integrity, these architecture models must themselves be standardized and integrated, enterprise wide, and they must be observed by all new initiatives and projects if you want to sustain a strategic direction.

This link is critical to keep in mind, yet we all forget or ignore it regularly. Here are some hints to help stay on course and mitigate damage if you don’t:

Don’t make the initial architectures, policies, rules and processes so involved and difficult that no one will follow them; Link them to the business culture;

Pay people to stay in touch with industry direction and incorporate that knowledge into your plans;

Set up architectural reviews early in project life-cycles and allow course corrections when new information indicates they are appropriate;

When you set up your architecture, follow industry models and standards whenever you can [and if you have to wait 6 months to do so – do it]; rolling your own and retrofit are hard work and make your direction tough to anticipate, and it’s much harder to integrate packages;

Set the “Target Architecture” goals for 6-18 months out so that new projects can anticipate what’s coming; and

Have a migration plan for non-compliant systems and use it as a “plan B” to retrofit the renegades that sneak by your standards and get implemented.

Another more organizational way of looking at it might be: