September 19, 2006
The Missing Link Between Application and Enterprise Architecture
I very often meet frustrated project managers and application architects complaining about smart-ass enterprise architects armed with high-level PowerPoint slide-ware about transformation, innovation and consolidation. It is unclear to these people how enterprise architecture (EA) can help them in their daily lives and they therefore see EA as a gatekeeper and resist the enterprise-wide perspective. But, why do we see this missing link again and again and how can we bridge the gap?
An EA tells the organization where they are on the IT map and identifies a transition plan for building a desired “to-be” architecture whose scope encompasses all of the computing of an enterprise. Application architecture designs, implements and maintains specific IT-systems. Hey, what is the problem?! The way I see it, the problem is the missing link is between the top-down EA work that defines and sponsors strategic IT projects and the bottom-up needs of business managers and innovative application architects.
I think governance and communication is two of the key ingredients if we want to bridge the gap between EA and application architecture. We need to define a clear link between processes for system development, project management, vendor management, capital planning, and strategic planning. It must be clear for the project managers and application architects how the EA program will help them in their daily lives and it must be clear to the EA program that they can not live in an ivory tower disconnected from the practical concerns of everyday life in the IT engine room.
I have seen some great example of how EA programs are reaching out to application architects. But, unfortunately, most of the programs I have seen are struggling to find the missing link. If any of you have experiences with this “missing link” please let me know. I will be working with my colleagues from IBM on this issue. Maybe they have some shelf-ware that can help us ;-)
Posted by khm at 08:20 AM | Comments (1) | TrackBack
October 18, 2005
Two Recommendations for Denmark
Last week I was in Denmark to meet with my colleagues in the Ministry of Science, Technology and Innovation, the IT-architect team at IBM, and my PhD supervisor at the IT-University of Copenhagen. The meetings were very productive; I think that my PhD is on the right track, the IBM guys liked my study here in the US, and the meetings in the Ministry were very positive.
Having studied the American (and Canadian) approach to enterprise architecture (EA) the last six weeks, my two preliminary recommendations for Denmark are:
1) Develop a business reference model for all levels of government: The last couple of years Denmark has been doing great in almost any eGov maturity survey. But, the way I see it, the future transformation of the Danish government needs to be facilitated though the use of reference models similar to the approaches taken in Canada and the US. The most important reference model is the business reference model (in Canada it is called the Strategic Reference Model, GSRM). Business reference models are used as a common language to identify opportunities for integration and collaboration across the traditional stove pipes in government. In this way, these models will enable the Danish government to consistently analyse current and future business processes across government, independent of established organizational structures.
2) Use EA to identify redundancies and new business opportunities: Because we have mainly used EA to promote interoperability in Denmark we have focused little on the business case that EA can provide. In my opinion, my employer, the Danish Minsity of Science, Technology and Innovation and the Ministry of Finance needs to work much more seriously with EA in their efforts to reap the benefits of digital government. The Danish government must move from EA concepts and take action by using EA to identify redundancies and new business opportunities.
Posted by khm at 12:02 PM | Comments (0) | TrackBack
July 20, 2005
Understanding the IS Heritage for EA
Contrary to what most practitioners (and some academics) seem to assume, the definitions of EA that we see in the emerging IS literature on EA should not be seen in contrast to IS traditions like Information Engineering, Information Systems Architecture or Strategic Information Systems Planning.
Traditional ISD and much of the IS literature about IE and ISA has a technical focus where the basic idea is about producing a project plan, not choosing the project or, even better, providing the framework in order to choose. This type of planning is practical at the systems level but leads to lost business opportunities and incompatible systems, data stores and architectures. Here, a typical EA encompasses an overview of the entire information systems – including software and hardware. According to Schekkerman (2004) modern EA is a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organizational structure, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructures of the business such as computers, operating systems and networks. In this sense, EA is a multidimensional discipline with an extensive scope that needs to cover a wide variety of viewpoints, deliverables, and processes across the whole enterprise. A fully articulated architecture constitutes enterprise architecture: the integration of business, data, information, and technology into a coherent whole. In the figure below, I have tried to illustrate this distinction between a business focus and a technical focus placing the different IS traditions into a simple two-by-two matrix.
The Y-axis in the figure represents the business and process focus that is evident in the SISP approach. Along this axis IS business needs and the possibility to gain a competitive advantage from implementing IS is considered while the technical implementation “details” and alignment is less important. The other axis in the matrix, the X-axis, has a technical focus where data and technical ISA’s are considered most important in the development of IS. Here we find the data focus in IE and the technically focused ISA’s.
EA is placed in the upper right corner of the figure because it claims to have both a technical and a business focus. The dotted read arrow illustrates the IS evolution; starting as a technical discipline in the 1960’s, IS began to focus on business needs in the 1980’s and 1990’s with SISP and trends like BPR, and we now see EA claiming to encompass all the different domains in the IS discipline in on holistic perspective, including enterprise design from organization, information, systems, products, processes to applications.
Posted by khm at 10:04 AM | Comments (0) | TrackBack