Having worked with so many different clients on so many different projects, we’ve learned a number of things that form the basis for our approach to business and technology architectures. First off, it is all about business need. Understanding this and then helping businesses to achieve their goals is at the heart of business architecture. But what exactly is a “business architecture” and how can constructing one be of any use?
Every business has an architecture, whether it has been formally captured on paper or not. But the act of investigating a business and describing it (an “as-is analysis”) is the first step in identifying opportunities for improvement. You cannot effectively change/improve what you don’t understand. This was the mantra of the Business Reengineering movement started by Mike Hammer. Others, such as John Zachman advocated the development of business architectures so that more appropriate IT solutions could be created in order to support businesses. Both of these viewpoints are valid.
A typical business architecture will describe the business/organization, what its purpose is, what services it provides, who it provides them to, what information is important, and what partners it depends upon in the delivery of its services. It’s the equivalent of a blueprint for a business. And with this business blueprint in hand, decisions regarding whether some action should be taken or not can be made from an informed position. For example, one could ask how a particular proposed project outcome supports the stated goals of the business. But it can go beyond this. Detailed business processes are a normal part of a business architecture. This provides necessary insight for process improvement (or even more invasive business process reengineering) and for ways in which automation can be effectively applied.
