Those of us who have been around the block a few times in the industry will have encountered many different types of ‘architect’ over the years. I even have a friend who is a real architect – he trained for about 10 years before going on to design hospitals, bless him – and he gets greatly irritated by us Johnny-Come-Latelys in the IT and even business domains who toss the term ‘architect’ around like it’s going out of fashion. I’ve even met a Golf Course Architect, believe it or not. I fully expect to hear of a ‘Consumer Product Display Architect’ (shelf stacker) on my next trip to the supermarket.
But a scout around the job boards, or a brush with a big enterprise or systems integrator, will reveal a certain breed of ‘architect’ known as an Enterprise Architect. Note the capitalisation; it’s important. An Enterprise Architect is more likely to have been to business school than they are to have ever been near an Inversion of Control Container. They come armed with a plethora of professional certifications, usually TOGAF and PRINCE2, and are extremely fond of enormous diagrams, exotic acronyms, 300-page foundation documents and Capitalised Framework Names.
If I sound dismissive, I’m not alone. Enterprise Architects have a reputation for bringing enormous levels of complexity and overbearing formality to a project, and for viewing software architects as the little people who worry about the unimportant detail of what the software actual does. If you’ve worked in a mid- to large-sized enterprise, you will probably also have noticed the outputs of Enterprise Architecture initiatives (unified timesheet, expenses or holiday booking systems, for example) are not exactly known for being the pinnacle of best practice. “Worst. Software. Ever.” is how one of my colleagues pithily described the holiday booking system at one company I worked at.
But despite the antipathy between software architects and fully-capitalised Enterprise Architects, I do believe that Enterprise Architecture as a discipline has an incredibly important role to play in the future of business. This is a theme I will return to in later posts, but the relentless onslaught of ubiquitous computing means that the need for joined-up thinking across all IT systems in an enterprise has never been more important. Enterprise Architecture attempts to provide some sort of ‘organising logic’ to the design of IT systems and how they fit into, support, and advance the commercial and operating interests of the enterprise.
What has become much clearer over recent years is that Enterprise Architecture is, first and foremost, a business-led discipline. It is driven by the ‘operating model’ of the enterprise (how the enterprise conducts its business, how it intends to grow). For the seminal work on this, I’d recommend the book Enterprise Architecture as Strategy by Ross, Weill and Robertson – definitely not a book for the IT professional, but essential reading for anyone interested in business management.
In a similar vein to Conway’s Law, I think the former Chief Enterprise Architect of BT, Jim Crookes, summed up quite nicely why Enterprise Architecture is so intimately bound to the way a company is structured and run:
“Companies get the systems they deserve. A company’s systems estate is a result of its culture, organizational history, and its funding structures. Coherent, well integrated systems will only ever exist in companies that value coherence and integrated service.”
If you hadn’t already guessed the importance of emphasis in the term Enterprise Architecture, it refers to the discipline of architecting the enterprise. Software architects interested in non-capitalised enterprise architecture, on the other hand, are concerned with architecting enterprise-ready software. I’ll list out some of my favourite books and resources for the latter in a later post.
Rather than eyeing each other suspiciously, enterprise-minded software architects and Enterprise Architects need to work towards a goal of meeting in the middle and recognising each other’s value and importance. I think that the philosophy of DevOps is an important step on the road towards software architecture professionals recognising the need to design systems for operation (i.e. what is important to the people who have to install, maintain, support and operate their software), rather than just to pass QA. Software teams need to become a lot more outward-facing and less insular, and enterprise-minded software architects have a big, big role to play. I strongly recommend the book Release It!: Design and Deploy Production-Ready Software by Michael T Nygard for a great primer in DevOps thinking.
Enterprise Architecture is here to stay, and will become increasingly important as IT becomes so utterly integral to the way every business is run, even traditionally stuffy and non-technical businesses. At the same time, software architecture is maturing, and needs to reach out to the business-focused practices and terminology of Enterprise Architecture. If EAs are prepared to venture out of their ivory towers every now and again (OK, a little unfair), and software architects are prepared to see that the ivory tower is not in fact an ivory tower but a pillar that is holding a roof over their heads (OK, a little fanciful), then we can perhaps start to work together to architect the enterprise AND enterprise-ready software as two sides of the same coin.