When is it Time for what Architecture?
Are you sure the architecture efforts in your organization focus on the right topics?
I know I had some serious doubts whether some of my clients had the right architecture focus. Now I know why, and how to address this.
If you went to SAP TechEd 2007, you may have gotten so lucky as to receive a copy of Jane Ross's book ‘Enterprise Architecture as Strategy'. I had heard good comments about this book and started reading the first weekend I could free-up some time. After finishing the book I could draw some remarkable conclusions on when to focus on what architecture practices.
From Business Silos to Business Modularity
Ross conducted research in the area of how the IT function adds value to the business and concluded there are 4 stages to discern.
Stage 1 ‘Business Silos'. Here the focus is on departmental IT projects. IT acts as a supplier filling in IT requirements set by the business.
Stage 2: ‘Standardized Technology'. IT delivers IT projects results, but at the same time works towards better control over the IT landscape, by standardizing on technologies and solutions being used in the landscape. Projects are stimulated to use these standard technologies and solutions.
Stage 3: ‘Optimized Core'. A core set of business processes is supported by a set of standardized business IT functionality. IT engages with the business on the use of this standardized functionality.
Stage 4: ‘Business Modularity'. Business process and IT extensions are created on top of the Optimized Core. IT offers a set of services for these extensions or the standardized interfaces of the core allow the business to develop these extensions by themselves.
I think this is pretty recognizable for many of us. Plenty as-is SAP landscapes have characteristics of the ‘Business Silos' and ‘Standardized Technologies' stages. The ‘Standardized Technologies' stage strives for re-use and it is mostly ‘design-time re-use', not so much ‘run-time re-use' we see here. I associate design-time re-use with using e.g. the SAP Enterprise Portal in different projects, but doing more or less new implementations based on this technology for each new project. Or a SAP kernel, that is rolled out and copied to different operating companies in an enterprise. In design-time re-use it is the designs and the experience that is being re-used.
Stages 3 and 4 implement a services-based landscape like SAP's eSOA. A single instance of a solution is re-used here in different projects. This is ‘run-time re-use'.
Organizations go through the stages sequentially, and skipping stages is much sought after but almost never achieved. However, not all organizations are expected to strive for stage 4.
Governance practices
Now Ross adds to this the IT governance practices that fit each of the stages. And what is interesting here, these practices came from research and interviews with some 120 CIO's. I listed most them below:
- Stage 1 practices:
business case, project methodology - Stage 2 practices:
stage 1 practices + centralized standards team, formal architecture compliance and exception, project architects, centralized funding - Stage 3 practices:
stage 1 and 2 practices + senior executive oversight, business leadership of project teams, enterprise architecture guiding principles, process owners, IT program managers - Stage 4 practices:
stage 1, 2 and 3 practices + technology research and adoption process, full-time enterprise architecture team, post-implementation assessment
A word of caution is appropriate here. A practice emerges at the phase where it has the largest increase in value. So e.g. a ‘centralized standards team' can be found in organizations that are actually in stage 1, but it has the sharpest increase in value in stage 2, and remains valuable as a practice in stages 3 and 4.
Remarkable conclusions
I think we can draw some remarkable conclusions, supported by the Ross's research from these staged governance practices:
- Organizations in the ‘Business Silo' stage should focus on good IT project execution and proving business benefits of IT. They might start work on architecture as a governance practice, but this will not be perceived as adding a whole lot of value. Architecture practices that are started in stage 1 are there mostly to prepare for stage 2.
- Before IT has achieved control over the IT projects (achieved in stage 1) and the IT landscape (achieved in stage 2) it will be hard to get senior management involvement in IT related projects. IT earns its position at the table by showing it can ‘run IT as a business': results and control!
- In the ‘Optimized Core' and ‘Business Modularity' stages an organization grows towards a services-based business and IT landscape. Before arriving at these stages the IT function has learned to create results and control. These are prerequisites for stages 3 and 4. The complexity of the stages ‘Optimized Core' and ‘Business Modularity' requires that the homework is done. So building a services-based IT landscape is a ‘bridge too far' if you haven't done your homework in stages 1 and 2.
The above reveals the timing for different types of IT architecture efforts. Standardization efforts mostly in stage 2, a platform for services-based IT and for standardized business functionality in stage 3 and an architecture function working on business and IT flexibility in stage 4.
How would you characterize the architecture function in organizations you know? Is there a need to rethink the architecture agenda of these organizations?
