What is Enterprise Architecture in a high velocity software business?
If Mark Andreessen is right, and I think that he is, that “Software is eating the world” then it is worth remembering that every business is a software business.
John Deere tractors are now mobile soil analysis labs, Volvo cars implement the equivalent of an ESB for all their internal electronics, and airlines compete based on the speed and efficiency of the airport gate scheduling systems. To quote another visionary, “The times, they are a-changing.”
Give some thought to how your business is being transformed by how it, or its competitors, use technology to compete.
Let’s restate our opening question to be,
Cloud computing, also known as on-demand computing, is a kind of Internet-based computing that provides shared processing resources and data. Cloud Computing, cloud hosting cloud server.
“Where does the Enterprise Architecture profession need to go to add value to businesses whose very technology operating model is changing?”
If I recall those enterprise architects whom I know, few have fundamentally changed their operating model. Online, I still see recruiters advertising for Zachman and TOGAF experience, endure long discussions at conferences of mapping business strategy to IT components or initiatives and console friends in engineering bemoaning thick turgid documents describing roadmaps and standards.
HOW DID WE GET HERE AND WAS IT EVER A GOOD IDEA?
In the days of yore, change was slow. Infrastructure was expensive and you didn’t control your destiny. Purchasing decisions could and did take a long time, as did the delivery of the hardware. Software features from packaged applications were in thrall to customer councils in companies that were similarly slow to move and ship new features.
If today is an age of continuous delivery, back then it was fractal planning…everyone having to rely on another’s roadmap that was only partly shared and understood. Custom software development in-house was infected by / shaped by these expectations.
If we could expect our vendors to provide us with long term costs and delivery dates why shouldn’t we expect the same from our own developers? To be fair, this worked for a while. Who did banks compete with? Other banks. There was no comparison of feature delivery and agility between a bank and PopCap games. We didn’t grow up expecting new features every week. An unconscious but arresting ‘colusion of the similarly-paced’ reigned in our expectations.
So, Planning change — it’s direction and speed — was critical. While everybody was focused on their own application or system someone had to focus on what the whole corporate technology leviathan was lumbering towards. This is where the Enterprise Architects came in.
They made roadmaps showing how often we needed to renew software; how long it might take to replace a technology that was beginning to lag on skills support in the market; and how to effectively evaluate its replacement in core systems. All good and necessary things.
Of course, this set them apart from their colleagues who actually ran those systems, or used those languages etc. So began the great war of independence between architects and engineers. Any of us who have worked in large enterprises over the last 20 years have been involved in a few skirmishes between people classed as ‘doers’ and those classed as ‘thinkers’ (meaning — NOT doers.)
CONWAY’S LAW IS, FOR ME, THE MOST IMPORTANT IDEA EVER TO COME OUT OF ARCHITECTURE. IT STATES THAT ORGANISATIONS WILL TEND TO PRODUCE SYSTEMS THAT MIRROR THEIR COMMUNICATION STRUCTURES. SO THE IRONY OF THE SEPARATION BETWEEN THE ARCHITECTS AND THE ENGINEERS SHOULD NOT BE LOST ON US.
- * releasing software in small batches, fast.
- * working in teams structured around required expertise and mutual respect and not organisational silos or complicated blame inducing SLA’s.
- * getting everything out of the way that obstructs the delivery of customer value.
- * Automating the hell out of tasks that can be automated so that we can achieve 1 even faster.
- * REVIEW
- * RENEWAL
- * REFACTORING
- * RESILIENCE
- 1. Iteration 1: deploy a small infrastructure footprint to support just the creation and modification of staff contact information.
- 2. Iteration 2: extend by integrating with current Active Directory infrastructure….
- * Track small failures
- * Resist oversimplification
- * Sensitive to operations
- * Committed to resilience
- * Defer to expertise