The Art of Establishing an IT Architecture Program – Part II

Gary Silberg, Senior Solution & Enterprise Architect

July 16, 2018

In Part I of this blog The Art of Establishing an IT Architecture Program – Part I, I explored why a company would want to create an IT Architecture Program, when to create it, who to put on the team, and where in the organization the program should report. In this second part, I will examine key deliverables and how best to ensure the success of your IT architecture program.

What kinds of output should your program create?

There are dozens of different deliverables that can be produced by an IT architecture program. Some contain high-level conceptual models. These enterprise architecture documents cover business capabilities, applications, information assets, technology platforms, and security implementation for the organization. They provide input to business and IT strategies and roadmaps. Since the business environment is constantly changing, there are benefits to creating several different roadmaps that allow for multiple future scenarios.

Solution architecture deliverables cover topics for specific projects, such as application integration, software stack design, user interface guidelines, and approaches for testing, conversion, and transition to production. The most detailed deliverables focus on areas like physical database design and technology diagrams identifying computing, storage, and network infrastructure.

Deliverable alignment

As an architecture program matures, the content of deliverables becomes more consistent. Enterprise architecture frameworks influence the selection of business change programs. These provide input and direction to the resulting projects. Some IT architecture programs divide enterprise architects rigidly into major types, such as Business, Application, Information, Technology, and Security. I often see postings to hire architects who specialize in only one of these categories, for example, an “Enterprise Information Architect”. These distinct groupings tend to constrain the progress of your architecture program. It is more effective to have enterprise architects who are generalists and who can produce deliverables that knit these domains together into a holistic program to more broadly support the organization.

The alignment of projects with the enterprise architecture roadmap deliverable is important. However, the overall driver for solution architecture outputs is to ensure that the scope of a project’s business requirements is fully delivered with a quality solution that is viable in the longer term. The scope not only includes the actual solution features, but also must take into account the project’s business case. Architects contribute to the documentation of business benefits, cost estimates, and solution impacts. They also supply input to the most essential part of the business case—the approach to organizational change management that enables the business to create a baseline set of metrics and ensure the project’s business benefits are achieved after go live.

Indispensable architecture deliverable

If I were to pick one architecture deliverable to name as the most beneficial, it is the “Design Decision”. It can be used at the enterprise strategic level, but is most commonly used on projects. Architects resolve issues using a structured technique which gets documented in the Design Decision. It includes a clear definition of the issue, stakeholders who are affected, and a list of viable alternatives. Each option is evaluated against a set of decision criteria and one alternative is recommended. This is presented to the stakeholders and a decision is documented, including an explanation if the recommended alternative wasn’t chosen.

Design decisions can be used to deal with a variety of project issues, risks, and scope or quality deviations. By carefully documenting key decisions in a project, architects mitigate risk and promote decision-making based on facts rather than opinions and personal preferences. The attention to detail in the deliverable avoids the rework often needed when the same issue is reconsidered multiple times. Design decisions provide an effective historical record for the project, and are a useful part of the organizational change management program to explain the rationale behind the solution design. In cases where the decision results in a formal project change request, they provide valuable input to the change management process.

I have a general rule about any deliverable produced by the IT architecture program. Before you create any document, identify its audience and explain to them why you need to create it. If you can’t adequately explain the purpose of the document to its intended audience, perhaps it has no value and isn’t worth creating. It may appear obvious, but it must make sense to the recipients of the deliverable and provide value to the overall business. I have seen some architecture programs work diligently to produce hundreds of enterprise architecture documents, but the binders sit on shelves and have little to no impact on any kind of business transformation.

How can you make your program successful?

So you’ve convinced your organization to set up an IT architecture program and now you’re in charge. How do you start building the program? First, I recommend reading as much as you can about the company’s business. Start with things like annual reports and business strategy documents. Familiarize yourself with the current application portfolio and review some of the main change requests in the backlog. Read the scope documents and current status of major initiatives, both business and IT. Second, interview as many key stakeholders as possible. Ask the business people about their future plans and how they see technology transforming their area. Ask the IT people how they think they can enable the business to be more profitable using current and future technologies. Describe to everyone how an IT architecture program works and ask them how they would see it providing value. Try to find a few critical areas where the program can help the most.

IT Architecture Program Charter

Once you’ve gathered all this information, create the IT Architecture Program Charter. Put in it what you plan to do, when you will do it, and how you will measure success. Use metrics related to business outcomes, not counts of architecture deliverables or events. Identify significant stakeholders and their roles in the program. Define the governance processes for your work, including an executive steering committee and a working-level architecture review board. Formalize your communication plan. Present and discuss the charter with senior stakeholders by relating it to their current situation and motivation. Enthusiastically sell your plan, but be prepared for skepticism. Most executives don’t care about architecture standards or complex technology topics. Use as many recent case studies within your industry as you can find to exhibit what you plan to do. Revise the charter with the feedback received. For the program to have the broadest impact, it must be signed off by the highest executive level possible—preferably the CEO.

In a previous blog,  Do you need a Solution or Enterprise Architect?, I outlined the similarities and differences between a solution and enterprise architect. As you bring staff into your program, these two architectural roles correspond to the two basic methods commonly used after your charter is approved. You can start with one or the other, or try both at the same time.

Solution architecture approach

This approach involves hiring a small number of experienced senior solution architects and assigning them to important projects where they can provide value. Introduce only a few fundamental deliverables, typically the following four: 

1.  Business Architecture: solution overview, high-level functional and data scope, integration context diagram, security needs, and critical issues

2.  Application Architecture: business system functions, key work processes, end users, application component structure, and interfaces

3.  Data Architecture: major subject areas and their components and relationships, conversion requirements

4.  Technology Architecture: infrastructure configuration by environment (e.g. development, test, production)

Integrate these deliverables into the project plan, create drafts of the deliverables, and educate the project team on how they are used. Contribute to project success by filling any resourcing gaps. For example, pitch in with database or user interface design or introduce an important reusable routine. Demonstrate value to the project from the IT architecture program in order to build relationships and gain credibility. Introduce the Design Decision to the project when it will be useful. Communicate program results regularly. Continue to assign solution architects to projects until the program is positioned to contribute to strategies and roadmaps.

Enterprise architecture approach

The second approach involves creating a small cross-functional team to execute a time-boxed project to build an initial enterprise architecture deliverable. You will need to convince senior management to let you book time with some key business unit strategic thinkers to work with your senior enterprise architects. You are more likely to get the right people if you ask for several short periods of time rather than one extended duration. For example, try to get two days per week for three months. That works out to about 5 weeks of work per business person over a quarter of a year. Your architects will be working full time during this time.

You must resist any temptation to model the entire enterprise. This is a never-ending exercise and the business will quickly get tired of participating. From your own analysis of the company and technology trends, and from stakeholder input, choose a small number of topics to consider. After three months, if there are only a set of diagrams and slide decks and no initiatives with tangible value identified, it will be almost impossible to get a second chance to do enterprise architecture work. So try to choose topics for this initial work that already have some buy-in and support for change in the organization. Pick an area where you already have a good relationship with key resources who will champion the change. As the projects are kicked off, assign solution architects with the expertise required by those initiatives. When some of these projects begin to deliver value, ask for the next time-boxed enterprise architecture initiative. Try to keep the iterations as short as possible to deliver benefits in a timely manner.

I’ve seen many organizations start out with an enterprise architecture program and try to add a solution architecture component later. In fact, most articles about setting up an architecture program only cover how to set up an enterprise architecture team. This approach often fails because the enterprise architects are too theoretical and never actually contribute to any implemented solutions directly. To avoid this fate, I strongly recommend establishing your IT architecture program with solution architects first. In this way, you can build your organizational credibility by directly contributing to projects that deliver business value.

From my involvement with many different IT architecture programs, here are some other useful do’s and don’ts to consider:

Do

•  Build and execute a written communications plan early (don’t just hope you’ll get around to it)—spend some real quality time thinking about the variety of stakeholders, what they care about, and how you can get their attention in short focused messages.

•  Produce regular program updates (monthly is typical) and report against the metrics from your program charter.

•  Communicate successes often through numerous channels and make the announcements stand out.

•  Periodically hold an internal celebration of a valuable achievement with both business and IT staff.

•  Continually network within your organization to seek out new work and gather perceptions and direct feedback.

Don’t

•  Try to digitally transform everything at once—choose a small number of areas to start.

•  Focus on technology standards and ruthlessly enforce them.

•  Force solution architects onto projects that don’t want help—go where you are wanted.

•  Build countless complex models about the current state of business and IT—focus on future initiatives.

•  Get bogged down in detailed architecture methodology—do just enough to be pragmatic and beneficial.

I have now covered the Why, When, Who, Where, What, and How required to set up a productive and professional IT architecture program. I hope my suggestions help you demystify the art of establishing an IT architecture program in your organization. One of the aspects that mature IT architecture programs find most rewarding is the enhanced collaboration between the business and IT. The enthusiastic personal interactions you’ll experience on your transformation projects make all the hard work successful and worthwhile. Good luck with your IT architecture program journey!