It’s time to add a new topic to this blog – business architecture. This topic will explore trends in business architecture and how the discipline of business architecture can improve the quality of IT planning, governance, and technology-enabled business transformation programs.
The question is: what is a business architect and where does the business architecture discipline fit in the context or IT architecture? Or is that the wrong question, and could it actually be entirely the worst place to start?
Over the last 40 years information technologies have been radically integrated into business processes and business models. At the same time, the relatively new discipline of software development has evolved and matured in order to keep up with the capacity, quality, agility, and speed-to-market improvements that business’s dependence on IT has demanded.
As these two trends collide, the importance of the software development discipline to the average organisation has peaked. Pure software development, no longer a core competency of the average organisation, is now a commodity. The paradox is that while software development is now a commodity the need to integrate information technology into business models is more important, and more difficult than ever. Add to this the oft-sighted failure rates of large corporate IT projects and it could be said that while software development is a commodity, successful software development is scarce resource! Less cynically, the real lesson that has been learnt is that successful software development is only possible within the context of a clear understanding of the business needs that drive the software development effort and the business changes that are implemented alongside the development effort.
Software development has been commoditized precisely because successful software development, and a successful IT function, must be managed within an overarching continuum of service-based management disciplines, outsourcing contracts, technology-enabled business transformation programs, and business knowledge.
So the history of the last 40 years of the IT industry has been to learn that successful business IT requires an understanding of the business. Unfortunately, this can be as a profound a lesson as it is practically meaningless. It’s like learning that a hand must fit a glove or that a successful puddle is made when the water exactly aligns with a hole in the ground. This is why there are still failed projects and there are very few artifacts being developed that formally describe businesses – even when they are sorely needed. Practical solutions aside, the lesson is in theory very simple – in order to take the risk out of IT success you need to understand the business with as much of a formal framework as you understand other parts of the solution – you need a business architecture.
It’s a natural question to follow that if you need a business architecture then you need a business architect. After all, you develop a solution architecture by employing a solution architect. But if we look for business architects we will simultaneously find them everywhere and nowhere. Very few professionals with the title of business architect live up to the promise of that name. Yet there are many who inspire us with business architect skills. These are the business founders, the innovators of new business models, the entrepreneurs, the so-called leaders who went that one step further and created an enduring legacy in the organisation or the cause that they created.
In short, business architects are hard to find if you look in the wrong place. You wont find a business architect if you look at your IT team or if you look at a team of architects. Business architects are more likely to be found architecting businesses. The only issue may be that those architects may not be sharing in a systematic way. We must take the step of turning the successes of these people into systematic success.
We may think that business architecture belongs at the pinnacle of IT architecture because business architecture has long been an aspirational end game for IT architects. Conceptually, business architecture is at the top of the pyramid because we’ve built a model of IT architecture that places it at the top. In fact, if business architecture isn’t at the top of the IT architecture pyramid then the whole model breaks – and perhaps it must break.
As the software development discipline has evolved the value of the architect skill set has been continuously reconfigured and applied to more business critical domains. While ‘system architecture’ originally might have referred to the physical systems present in microchip and motherboard design, the architecture skill set was then quickly applied to software domains. From there it further expanded and segmented into integration architectures, platform architectures, and application architectures. The term system architecture was then co-opted to include multiple software components – expanded again to integrate the software components and the hardware components because they make up the entire system. This expansion and segmentation continued. The software and hardware architectures were combined to become the ‘solution architecture’. But the ‘solution’ wasn’t just hardware and software so the term ‘solution architecture’ was refined again to encompass the context of what was now the technical solution as well as the business process change, financial modeling, and partnerships that supported the solution.
This continuous expansion and segmentation is as complex a history of a profession as you can imagine and it’s been played out over a relatively short period of time. The debate on the exact definitions of various types of architectures will likely continue. But right at the top is business architect. Unfortunately, this leaves the most important level of analysis and specialization of the architecture discipline sitting precariously on top of a towering bundle of seemingly never-ending debates about architecture artifact, views, meta-models, and architecture governance.
Business architecture is seen as the shining gold at the top of an overall architecture framework. This is not the place for it. Those foundations are weak, contain much that is irrelevant, and form an historic edifice that must be climbed with each discussion – losing many travelers on the way.
It’s time for business architecture to stand on its own. Its value is potentially greater without the supporting infrastructure that has built up below it. In fact, it’s likely that it’s not even the right foundations for business architecture. It’s likely that business architecture has a closer relationship with economics and politics than it will ever have with IT architectures. There is much to learn from business architecture as a type of architecture but never as a type of IT architecture.
People are using business architecture when they are analyzing the dynamics of an existing or imagined business. But they are likely not to be designated with the role of a business architect. They are more likely to be planning a large-scale business transformation program, or running a business, or managing risks. They might also be advising on the same processes – based on both deep experience and deep thinking about organisations. But even those advisors are also unlikely to want to be called a business architect.
So this blog will be an exploration of business architecture as it standards alone – not built on the foundations of information technology or IT architecture disciplines (but often alongside the application of technology to business), nor will it assume there is a specialised business architect role built into the discussion.
This is a blog about the nature of businesses and the why they create value. It is also a blog about how this process needs to be understood by multi-disciplinary teams trying to understand, build, operate, or change businesses. I’ve started by throwing out the misconception that business architecture is part of IT architecture – but we also need to go one step further and build a body of knowledge which doesn’t assume there is a role of a business architect who may or may not exist. So… Where do we go from here?
Note: the title of this post is from a booked call “What, if anything, is an architect?” (http://catalogue.nla.gov.au/Record/1115632). Image credits:
http://venturebeat.com/2010/04/22/microsoft-joins-with-dell-to-tackle-e-waste-on-earth-day/e-waste/ and http://internetsiao.com/the-gold-bar-doorstop/.
