The secret art of technical architecture improvement

Choose one word to describe your company’s technical architecture and it would likely be “really complicated.”

Okay, that’s two words, but most technical architectures really are really complicated. Figuring out how to simplify and improve them? We’ll need to repeat “really” a few more times: That’s really, Really, really complicated.

Of course, when anything is that complicated — or convoluted — it helps to break things down before building up an improvement plan. Here, we do just that, helping you hack off a few of those “reallys” so you can put a practical game plan together to ensure your company’s technical architecture best serves the business.

Untangling technical architecture

A previous installment in this series provided a framework for describing technical architecture, breaking it down into three portfolios and their sub-portfolios:

• Applications: systems of record, interfaces and integration, and satellite apps
• Data: both structured and unstructured
• Technology: facilities, infrastructure, and platforms

The next installment added the idea that technical architecture requires two complementary perspectives: the portfolio view and holistic design. It also provided guidance for evaluating the health of the components that make up the architecture.

And it showed how to connect the technical and business architectures, specifically through the “business capability model” (BCM) — a business function taxonomy to which each application in the technical architecture maps.

Together they let you identify, categorize, and rate what you have.

But to get from here to establishing an effective plan for improving your technical architecture, you need to determine, for every component in each portfolio and sub-portfolio, its disposition — how it needs to change — and the priority for making its disposition happen.

The specifics depend on which portfolio and sub-portfolio you’re dealing with. Here we break that down, from the bottom up.

Facilities and infrastructure

In improving technical architecture, establishing priorities is always your first priority. Score each component’s health using the process, framework, and criteria described in the last installment. Score its importance based on how many applications rely on it. Multiply health by importance to compute a priority index for each component. Visualize the result as a heat map, where the redder the component the higher its priority.

Dispositions come next. For facilities and infrastructure, your disposition choices are:

• Retire: While it’s unlikely, it is possible you’ll identify facilities or infrastructure that aren’t in use. Turn them off, shut them down, and cancel any leases or support contracts.
• Update: You might find components of your facilities or infrastructure that are obsolete, unsupported, or otherwise in need of updating to more current versions of the same product. Update them.
• Replace: You might find a component that is obsolete, unsupported, and if there is a more current version available you don’t consider it viable. Get rid of it and deploy a functionally equivalent but healthier alternative in its place.
• Consolidate: It isn’t unusual for a technical architecture to have redundant facilities or infrastructure components. Especially following a merger or acquisition, multiple data centers or networks often offer consolidation opportunities.

You now know, for facilities and infrastructure, what needs attention most urgently and what to do about the situation.

Platforms

Determining platform priorities and dispositions differs from determining them for facilities and infrastructure because platforms have far more interdependencies. A good way to deal with this complexity is to define stacks. A stack is a combination of platforms used by at least one application, including the server OS, development environment (including libraries), DBMS, CMS (content management system), web server, and supported browsers (assuming the application’s UI is exposed through a browser), plus the operating systems on which the various platforms run.

It’s worth noting that stacks are recursive: Platforms can rest on other platforms. It’s also worth noting that some applications can also be platforms. SharePoint, for example, is an application that can also serve as a development environment for building custom applications.

Priorities: A stack’s health is the average health of its components, scored using the process, framework, and sample criteria documented in the previous installment of this series.

Its priority? There’s no infallible “best practice” for this. An approach that cuts through the complexity is to identify the unhealthy platform that, if remediated, improves the most stacks the most. To illustrate, imagine you’ve defined 60 stacks in your technical architecture. Also imagine the unhealthiest platform you have in production is Windows Server 2003 — give it a hypothetical health score of -1.5.

In this hypothetical example, imagine that raising its score to +2 moves 14 stacks from -1 to 0 and another 6 stacks from 0 to +1. That’s 22 stacks improved by fixing Windows 2003 Server. Windows 2003 Server’s priority index is 20 out of 60 stacks improved: 0.33.

Rinse and repeat for every platform component and you have a useful way to rank platform priorities.

Dispositions: Platform dispositions are similar to those defined for facilities and infrastructure:

• Retire: While it’s unlikely, it is possible you’ll identify platforms that aren’t in use. Turn them off, shut them down, and make sure to cancel your license agreements and support contracts while you’re at it.
• Update: You might find platforms that are unsupported or otherwise obsolete. Migrate them to more current versions of the same product.
• Replace: It’s not uncommon to find a platform that is obsolete, unsupported, or, if there is a newer version available, you don’t consider it viable. Get rid of it, deploying a functionally equivalent but healthier alternative in its place.
• Consolidate: It’s a rare technical architecture that doesn’t have redundant platforms in use. Between server OSes, DBMSes, integrated development environments, and so on, establishing those with the highest health ratings as company standards and migrating the rest to those standards can offer rich opportunities for simplification and improvement.

Data

In theory, data repositories should be considered independent targets for improving technical architectures. In practice, these are dealt with as part of application dispositioning, not as independent assessments and plans.

Except, that is, for an organization’s data warehouses and other analytics repositories. These should be dealt as separate data-layer components. But because they’re managed by the organization’s analytics practices, they’re Someone Else’s Problem. You can safely exclude them from your evaluation process.

Unless, that is, one or more platform layer dispositions affects an analytics repository.

That’s one of those cases where the technical architecture becomes political.

Applications

Now it gets interesting.

You can score application health just as you scored the health of the components in the lower layers of your technical architecture: just average the evaluation criteria scores to get an overall application score.

Priorities: It’s not uncommon for even a midsize enterprise to have hundreds or thousands of applications in their portfolio, so establishing priorities one application at a time is impractical. Nor is establishing application priorities even a good idea. You’re far better off considering priority as a property of business functions and the application mappings you’ve already documented using the business capability model.

In most technical architectures, each business function is supported by one, or possibly two core applications, often modules from an ERP package or other broad suite.

Core applications are surrounded by satellite applications that provide functionality missing from the core application. Satellite and core applications share and synchronize data with each other.

In addition, many business functions make use of utilities — applications that stand alone and require no integration with other applications supporting the business function in question.

To determine priorities, start by calculating a business function application health index as the weighted average health of the applications that support it, assigning a weighting factor of 10 to core applications, 3 to 7 to satellite applications, depending on each one’s size and scope, and 1 for utilities.

You should already have the business function’s health recorded — that was provided to you by the business architecture team as part of its BCM.

Your top priority is the business function with the worst combination of business function health and application health.

Dispositions: Technical architects have more alternatives available for dealing with applications than with the lower layers of the technical architecture. Specifically, for each application you can:

• Retain: Continue to use the application, maintaining and enhancing it as business needs change.
• Replace: Get rid of the application, substituting a functionally equivalent but overall healthier alternative.
• Re-platform: “Lift and shift” the application to a lower-cost but otherwise equivalent set of platforms.
• Refactor: Rewrite the application to conform to your technical architecture engineering standards.
• Adapt: If a platform is going to change (see platform dispositions, above), some applications will need to change with it.
• Consolidate: If an application is redundant — i.e., a functionally equivalent but superior application is in use elsewhere in the enterprise — migrate to that application, especially if it’s been deemed the go-forward company standard.
• Retire: Unplug the application and cancel its licenses. If the situation calls for it, archive the application’s data first.

What about the cloud? The cloud is neither irrelevant nor important for this analysis until you’ve finished assigning application dispositions.

Once you’ve done this, if your technology strategy includes cloud migrations, the cloud might be the right choice for replacing, refactoring, or re-platforming an application.

From priorities and dispositions to a plan

Many technical architects, steeped in the waterfall approach, consider a roadmap, with a Gantt-chart-ish view of a disposition timeline, to be the most important artifact when planning technical architecture improvements.

But a roadmap is a relic of waterfall thinking. There’s little point in planning technical architecture changes beyond the top priority platform or business function, until the top priority disposition plan is well under way. As we’ve learned in agile application development, a plan made too far ahead is a plan that will be obsolete long before the time comes to get started on it.

Managing technical architecture planning through an agile-style backlog is far superior to a classical roadmap.

There are two variations to this approach — platform-driven architecture and business-function-driven architecture. In the first, platform stacks take the place of agile “epics” in the backlog. The second builds its backlog epics around business functions.

Platform-driven architectural change: With this approach, one platform component will usually be selected, whether based on priority-setting as described above or some alternative that fits your organization better. Either way, planners will look for platform-level ripple effects (other affected stacks) and application-layer ripple effects (applications that make use of any of the affected stacks).

Midway through implementing the top-priority platform disposition, technical architects will review current platform epic priorities in the remaining backlog and, if appropriate, modify them to fit changing circumstances, then begin the planning process for the next-highest priority epic.

Business-function-driven architectural change: With business-function-driven architectural change, while it’s true that correlation doesn’t prove causation, functions where business and application health are both rated low are a reasonable place to look for application deficiencies that are causing business process bottlenecks.

From the perspective of technical architecture, business-function-driven change begins with the disposition of the top-priority business function’s core application and flows out from there to satellite application dispositions.

In parallel, the company’s business architects will collaborate to design and implement process improvements enabled by the application changes.

As with platform-driven change, midway through implementing the dispositions of the top priority business function’s applications, technical architects will review and, if appropriate, adjust backlog priorities and begin planning for the next-highest-priority epic.

And in conclusion

Had enough?

Technical architectures are complex. They have to be, because if you’ve ever tried to document everything that has to happen in the business so it can design, build, sell, distribute, and support its products and services, you know the business is complicated.

This is, by the way, what your BCM does. It isn’t uncommon for the first three BCM layers to list a few hundred business processes and practices. Likewise, it isn’t uncommon for the applications mapped to the BCM — your application inventory — to number a thousand or more.

The process for documenting everything you have and planning whatever improvements are called for is time-consuming and expensive.

But that’s okay, because not documenting everything you have and planning necessary improvements ends up being even more time-consuming and expensive.

When your choices are pay it now or pay it later, the one thing you can count on is that paying it later is a whole lot worse.