I’m working on a (probably) three-part sequence on technical architecture, to be part of the IT Management 101 series I’m writing for CIO.com. As a famous person once said about health care, who knew architecture is so complicated?
This isn’t a substitute for it. It’s more along the lines of stray thoughts you might find helpful in assessing and managing technical architecture in your own organization.
Beware the seductive siren call of metaphor. The parallels between technical architecture and what professional building designers do are limited at best, and dangerous at worst.
The work of professional architects begins with a sketch and ends with blueprints. Technical architects don’t create blueprints, and if they did they would be embracing waterfall methodologies.
Agile methodologies don’t rely on blueprints of any kind. They often do rely on the equivalent of a sketch, but if so it’s the business analyst / internal consultant who draws it.
Crowdsourcing is a dicey way to gather data. Given how much information you’re going to want about each component in your portfolios, crowdsourcing it … sending out questionnaires to subject matter experts … is tempting.
Given that many enterprises can have a thousand or more components across all of their portfolios, crowdsourcing might not just be tempting – it might be unavoidable.
So if you do crowdsource your data-gathering, make sure you educate all of your information sources in the nuances of what you’re looking for.
And, assuming they do complete your questionnaires, curate the daylights out of the information they provide.
Version is data. Currency is information. You should include in your technical architecture database how current each component is, “current” meaning whether it matches what the vendor currently ships (fully current) or, descending through the possibilities, whether it has fallen out of support (obsolete).
Keeping track of which version of a component is deployed in production is relatively straightforward – just make sure than any time the responsible team installs an update they know to update the architecture database to match.
But what you care about is how current the component is, and you can only determine that if you know the product’s full version history, so you can match your production version to its position in that history.
Currency scores are, of course, perishable. As they change each time a vendor issues a new release, someone needs to keep track of this across every commercial product in every portfolio in your architecture.
It isn’t just your technology that has to stay current. You have to keep every piece of information you collect about each component in your architecture current, too.
You collect information about each component of your technical architecture. Some of it is constant. But quite a lot may change over time. For example, you’ll probably want to know how well each application supports the business functions it’s associated with. But business functions change, which means an application’s business function support score changes along with it.
So your information-gathering process has to operate on a cadence that balances the sheer effort required with the rate of decay of information accuracy.
Bob’s last word: Speaking of balancing effort and information it’s tempting to collect a lot of data about each component in the architecture. Tempting, that is, until you pivot from collecting it the first time to updating it on a regular cadence, over and over again.
In the framework I use, I’ve identified about 30 attributes just for the application layer of the architecture. That’s a starting point. An important part of the process is whittling them down to the essentials.
Because 30 is too big a number. Ten will usually do the trick.
Bob’s sales pitch: I’m still whittling down the CIO.com architecture articles to their essentials. I’ll let you know when they’re available for your reading enjoyment.
“Bob’s last word: Speaking of balancing effort and information it’s tempting to collect a lot of data about each component in the architecture. Tempting, that is, until you pivot from collecting it the first time to updating it on a regular cadence, over and over again.” true of almost every system – including the database of which person knows what about which component!
Typical agilista nonsense using a logical fallacy to convince themselves they are right.
There are other ways to achieve proper architecture without waterfall. And yes, it takes more work and more time which requires reasonable compromise between perfection and what is possible. But compromise is not in a hackers vocabulary when their only personal goal is sprinting faster.
Everything has an architecture whether you explicity devise it in advance or you take whatever results from bumbling hackers using trial and error agile techniques. You can agile your way across a creek by cutting enough logs until you can create a bridge of sorts. But crossing a canyon requires engineering with planning in advance.
The technical architecture noted is ONLY ONE of many supporting architectures of a total and complete, correct, SYSTEMS architecture. Without considering ALL aspects and impacts of the decisions we have the risk of other unexpected consequences that are far worse than whatever gain the tech arch may have provided.
The fundamental law of systems says that you cannot optimize the system by optimizing the subsystems. The corollary is that optimizing a subsystem will make the entire system less than optimal.
When IT goes forth assuming it is the only thing that matters and tries to do the best that they can with the IT technical architecture then the enter enterprise will be the loser for not reining in the agilista hackers who try to make their job easier while achieving any result that the suits will accept.