What architects should be doing (and mostly aren’t)

Suppose, just suppose, you are called into the CEO’s office. Then suppose the CEO says “justify this group called enterprise architecture”.

What are you going to say? — because “well, everyone else has one and so we need one too” probably isn’t going to do your career any favours.

The Setting of Bounds

Enterprises are complex adaptive systems operating in a complex adaptive world.

That’s not just a “phrase of the month”. It points to enterprises as places where initiatives stem from multiple teams, not under the direct control of the people at the top — and that, to succeed, that kind of initiative has to be the norm.

For a Chief Information Officer, that means that there will always be IT-related work being done elsewhere than in the formal IT group. In an era of smart phones and tablets, cloud-based services, and personal computing software capable of processing more data than the mainframes of thirty years ago would have been comfortable crunching, how could it be otherwise?

Now, as anyone who’s ever organized anything knows, there’s a balancing act involved in letting the thing happen with optimal results. Too many rules and boundaries, and the initiative and ability to coalesce around what’s working is hampered or even stops. Too many consultations, and nothing happens but talk. Too few bounds, on the other hand, and the channelling of energy toward the optimum also stops as efforts dissipate.

So the first job of the architects is to lay out the playground (so to speak) — setting some bounds and conditions, but otherwise leaving the field free for initiatives (solutions) to emerge.

Even ten years ago, it was different: there were far fewer options available for those who wanted to create their own solutions (and their cost made many of them more visible) and much of “architecture” was replacement of application portfolios with packaged solutions.

Today, in an era of “bring your own device”, “bring your own application”, and cheap points of entry, setting the bounds that channel these into paths where integration can occur is a useful service — far more useful than acting as the gatekeeper for absolutely everything.

Integration of the Parts

Getting disparate parts to work together is the next and equally important role of architects.

More and more systems are integrating with non-IT components (I call them “non-IT” because the suppliers involved are not traditional IT vendors. This is both a result of the digitization of most other lines of business, and the ability to sense more of the world using the emerging “Internet of Things”.

From sensor antennae reading RFID chips on selling floors and plant floors, to sensors tracking body heat to see traffic patterns, to digital broadcasting equipment, to a host of other devices, what has to be made to work together goes far beyond the things the IT group traditionally dealt with.

Cloud-based suppliers, in turn, put applications beyond integration by modification. Moving data in and out of them now requires that transforms or insulating layers be built where needed (for instance, to inject data into your ERP investment).

Architecting these as utility infrastructure — in-house middleware, if you like — rather than building individual “connectors” on an ongoing basis is the lower cost, longer term way to deal with “too many moving parts” — and to make intermediate data available for analysis (or even sale as “data products”, if your line of business supports that).

Bringing down the Total Cost to Own and Operate (TCOO)

A project hits the bottom line once, its outcome preys on the bottom line year after year.

Architects should be expected to have a sense of the cost of following one set of options for IT over another — and to ensure that the enterprise, over time, brings its total cost to own and operate its information technology down.

Some of the items become bounds within which people make decisions; more of them are recognizing that as parts are integrated and updated the long term direction should be upheld.

This is why, for instance, the boundary condition “licensed code shall not be modified” might be put into play — it removes future cost from TCOO for retrofitting mods, and removes the upgrade limitations modifications impose (from an unwillingness to pay again).

At the same time, another boundary condition about security requirements might be put into play, even though it ostensibly is adding cost, simply to ensure all the moving parts will play well together without creating anticipatable exposures to the firm’s assets.

The Upgrade Cycle

Multiple factors come into play for existing assets to help determine their lifespan. It should be expected that your architects are tracking these and injecting upgrades into the mix as needed to keep the asset portfolio operating without cost increases.

This means knowing and projecting the market value and availability of required skills, the value of new features from vendors (to know when to upgrade), the cost profiles of various platforms, and the opportunities to extract additional value from investments through deployment changes are all roadmaps you should expect architecture to be able to speak to — as well as give guidance on accelerating or extending depreciation and funding operating costs surrounding replacement in each year.

Differentiation Criteria

Architects, finally, should project likely risks, reward ratios, and zones of opportunity for differentiation in the portfolio. This sets a bound for project release that creates a favourable zone for provisioning code that differentiates the enterprise.

In general, differentiation produces new value on the top line, whereas commodity solutions support existing operations. The first deserves your best customized response; the second is implemented and maintained purely to reach the lowest possible cost.

Without having worked through potential zones of differentiation, architects really have little to nothing of interest to say to the business (as many, many meetings over the past decade have shown). With it, they become contributors in the process of building the future.

So — if your architects aren’t working on these — why not?


About Bruce Stewart

A philosophically minded politically interested fellow with more opinions than is probably good for him.
This entry was posted in Enterprise Architecture and tagged , , , , . Bookmark the permalink.

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