A couple of weeks ago, Accelare collaborated with Penn State and Gartner Research to produce a 3 ½ day executive education workshop entitled “Enterprise Transformation and Integration: Beyond IT/Business Alignment”. I taught one of the sections but I also learned a lot from the other faculty members. Last week I posted a piece entitled Four Skills For 21st Century Success based on a presentation from Al Vicere, Executive Education Professor of Strategic Leadership for The Smeal College of Business. A second excellent presentation was Business and Organizational Design by Sandeep Purao, Professor of Information Sciences and Technology at Penn State University. I am taking some significant liberties here to apply some of Sandeep’s concepts to the practice of business architecture.
Applying a systems lens to business architecture
Most architects I speak with (enterprise, technical, or business) promote the concept of systems thinking as a model for seeing the whole of the organization. However, rarely do they step back and think about the architecture practice from a systems perspective. Dr. Purao’s presentation got me thinking about this. He made a number of interesting points I have not seen others address in systems thinking discussions. Here is my take on them from a business architecture practice perspective:
Setting up systems. We propose to implement a business architecture practice to solve a set of business problems. Yet, when we set up a business architecture practice, we are introducing a totally new system into the environment. This new system must be integrated with all the other systems it interacts with and will create a set of problems all its own. So, by introducing the business architecture system, we have introduced a new set of problems for the organization.
Systems spawn problems. To be successful architects we must ensure we solve the problems implementing the business architecture system creates. For example, a business architecture program is set up to align strategic activities across the organization. Those who are used to working in silos are now being asked to collaborate and make joint decisions on strategic investments. Organizational conflicts ensue. Business architects see this as the business’s problem. But stop and think about it a moment. We created the business architecture system to solve the problem of disconnected planning and in the process, we created a new problem of organizational competiveness and culture conflict.
Systems tend to assume a life of their own. Once a system is established, it tends to see the world through its own lens. For example, business architecture practices tend not to create implementation functions. Why? Because business architecture is a strategy and planning function. Never mind that its clients want help at the tactical implementation level.
Large systems usually operate in failure mode. Business architects largely present business architecture as a solution to a myriad of problems. They focus almost exclusively on what is wrong with the organization rather than what is right and improving on that. Think about the difference between these two messages. I am here to fix your problems. I am here to help you leverage your organization’s capabilities.
The system tends to oppose its own proper function. Once a system is in place, it tends to set up a rigid set of rules that encourage people to break them. For example, a business architecture practice sets up a well-designed, but fairly rigid, collaborative investment prioritization process. However, some business managers go directly to the CEO for funding to circumvent the process, which leaves less money in the investment pool for others.