Tag Archives: Strategy

SOA for Profits

If you look for a great book on how to deal with the implementation and adaption of an Service-Oriented Architecture the book SOA for Profits is what you are looking for. The book was published back in 2007 but is still highly relevant. The focus is on handling the needed interaction with stakeholders to collaborate and define what have to be done and when it should be delivered in order to work around a burning platform for applications.

“The basic Concept is that all IT is composed of services” – Bieberstein et al (2007, p. 17).

Eventually the enterprise’s technical architecture will be compatible with an SOA typology and as such it might enable the enterprise to make use of the benefits, however, the benefits can only be achieved through the engagement of the various departments and decision-makers that makes use of the services that the IT department can provide them with.

Above all, Service Oriented Architecture is not only a development within the domain of IT, it also has a far reaching impact on the organization makes use of it” – Bieberstein et al (2007, 17).

By saying this it seems like the approach to Service-Oriented Architecture will involve much more effort and many more resources and stakeholders than what is firstly expected. The various departments outside the domain of the IT department would have to be involved in the transformation. This means that the development of the transformation program includes the development will become much more complex and the effort of communication will become increasingly difficult.

Assuming that the Service-Oriented Architecture program is much more than the programming exercise and technology adaption exercise the importance of technology, the organizational aspects of the organization will become of a much higher priority. This means that new strategies would have to be dealt with as well.

Indeed, the organizational aspect is of decisive importance” – Bieberstein et al (2007, p. 17)

It is in my opinion not a particular smart thing to assume distance the IT department from the other departments in an organization since it will only lay the foundation for the development of a stovepipe culture. Bieberstein et al (2007) doesn’t share this particular view and as such they make use of the notion of business and IT. In this case it can be unclear who the business is, however I presume it is safe to assume that the business is sales, operations, communication & marketing, call centers and a like. There are different levels also that would have to be taken into consideration e.g. those stakeholders who develops the strategy. The “business” would have to be engaged and Bieberstein et al puts emphasize this in the two quotes below.

“Another essential precondition in the implementation of Service Oriented Architecture is to start with the business” – Bieberstein et al (2007, p. 19).

Indeed, the organizational aspect is of decisive importance” – Bieberstein et al (2007, p. 17)

Clearly the implementation of an Service – Oriented Architecture is not without consequence and as such the primary problem is the recalibration of the social structure of the enterprise. Likewise is the sharing of a vision for SOA probably very difficult since not every individual in the “business” will invest time in understanding why they would have to define services or why they should collaborate with the IT department on anything. It will prove much more difficult if the IT department hasn’t been able to get the basics right in the past. In other words the Chief Executive Officer, The chief architect and the various other managerial positions within the organization would have to go on the upfront with communication and networking in order to ensure progress.

You can’t escape SOA

The authors present the concept of the SOA typology as inescapable.  The big vendors of enterprise-oriented software have already implemented the capabilities of SOA – protocols that enables the application to work with an enterprise service bus (ESB). As a result most enterprises will overtime experience that their applications will be made compatible with the SOA typology out of the box and as such it could be a waste of resources that the organization doesn’t make use of its technical capabilities. As such Bieberstein et al argues that it will become more likely that organizations will implement SOA like systems and eventually adapt the form of architecture. This the authors express in the quotation below.

SOA is inevitable in the long run. An increasing number of major suppliers and end-user organizations are applying SOA. This means that more and more software and hardware is being based on SOA, that an increasing amount of functionalities are being made available as services, and that a growing number of chains and co-operative endeavors are being structured in a service-based manner. This, sooner or later, there will be no escape.” – Bieberstein et al (2007, p. 37)

You can’t escape SOA because the ecosystem (suppliers and to some degree customers) expect your organization to make use of services.  With this in mind Bieberstein et al (2007, p. 55) states that the two most important functions to be deal with in implementation of SOA is enterprise governance and enterprise architecture.

The organization has to emphasize the implementation of SOA on the foundations of the progress of the enterprise architecture program. In their effort to implement SOA the stakeholders would have to collaborate extensively on defining, scoping and implementing SOA in the context of how the organization works. Enterprise architecture is to some extent the framework for the governance of the SOA Without governance the effort of implementing SOA will not succeed. The purpose of governance is partly to navigate the complexities of the ever-evolving IT-landscape (Bieberstein et al, 2007, p. 58).

Consequences by implementing SOA

The organization would have to deal with the consequences of implementation of SOA. A SOA project (and later on a program) is resource demanding, since it would have to allocate the time of enterprise architects, SOA specialists, business architects and business partners. Likewise will the SOA project allocate time from various stakeholders outside the IT department since they would have to be educated on defining business services that would be used to model the technical services upon.

The allocation of resources means that the organization would have less access to deal with projects that might be within the sphere of development with architecture. The major issue is the concept of opportunity costs and as such it would become a necessity to deal with the problems that arise from not being able to allocate all available resources. Bieberstein et al mentions the consequences on page 34 to 35 where they mention the consequence of the adjustment to business processes, governance of architectural process changes, IT development related to the processes and administration of process changes. Likewise will the SOA approach lead to a need for retraining of IT personnel and training of the stakeholders outside the IT department. In this context it become much more interesting to convince those decision-makers who are in charge of the budgeting to allocate resources to fund the training activities along side the need for new tools to govern the services.

Business Vision

In order to deal with the implementation of an SOA based typology it would have to be dealt with the articulation of a business vision. Bieberstein et al (2007, p. 23) named it the SOA business vision and it consists of five stages as listed below:

1. Reason has to come from both within and outside the organization (p. 31) and the legacy systems in the organization’s IT – landscape can prove to be a great platform for engaging in change. Bieberstein et al sees this as “.

2. Benefits have to be identified and the benefits would have to be articulated as specifically as possible (p. 31). Bieberstein et al sees this as the “why” question.

3. Definition is the “what” question and is according to the authors just as important as the “why” question to answer in order to articulate the SOA business vision

4. Consequences by implementing SOA are many e.g. training of the individuals within the enterprise, opportunity costs, acquisition of new tools

5. Implementation is the last of the five phases and includes the implementation of wrappers, protocols, ESB, business services, XML protocols and standards and the implementation of the organizational structures.

The core to implement a SOA typology in an organization is to have defined the proper SOA business vision and engaging the right stakeholders. Governance is a must and Bieberstein et al indicates that the framework Dynamic Architecture.

Dynamic Architecture

The approach to Dynamic Enterprise Architecture  (Abbreviated Dynamic Architecture) is a framework that focuses on the process of architecting. The scope of Dynamic Architecture is to focus on issues that aren’t a part of a speedy defensive strategy that demands the resources of the IT department to deliver it-based solutions and likewise it isn’t based upon an offensive strategy that demands development of applications or services needed to gain market share.


All in all, the book “SOA for Profits” is a great book dealing with the organizational challenges for implementing SOA. Many ideas presented in the book are necessary in order to gain the true potential of an SOA since it would take the development of systems and integration to the various organizational aspects of development e.g. the transformation of stovepipe orientation to a holistic process orientation. SOA is inescapable and eventually most organizations would have to adapt applications that have been optimized for a typology based on SOA.

The primary challenge to gain profit (or harvest advantages) by applying SOA is through the maturation of the organization and through the departments that collaborate on dealing with the data and functions needed in order to make the technical and business processes deliver the full potential.


Bieberstein, Norbert. Berg, Martin and Ommeren, E., SOA for Profits, 2007.

A Model for Literature on Enterprise Architecture

I have been working with several different perspectives on governance, strategy, it architecture and enterprise architecture. I have read several books on the three topics and as such I have been able to build a model for categorizing the literature.

The Model

The model is segmented into three different levels and three different categories. The first (vertical) category deals with information and how information is used. The second (vertical) category deals with strategy (you shouldn’t articulate a strategy that isn’t based on information). The third category (vertical) is about innovation since strategy is often about doing new things and do them well in order to move the enterprise.

The categories that are horizontal deals with different perspectives and as such as economy, organization and technology. There are some “blank” spaces in between the three horizontal categories and as such these should be seen as in the spectra of the three perspectives.

The various authors that I have organized in the model have been mentioned under the Harvard source notation standard e.g. Beer (1994).

The model is essentially constructed upon the same principles as Leavitt’s model for organizational and technological alignment which means that I can only recommend the reader to read books with-in all of the perspectives in order to gain a holistic understanding of what Enterprise Architecture is all about. The model is of course a simplification of the reality.

Feel free to contact me if you feel that other books should be added to the model. You can contact me by comment this blog post or using the contact form.


Anderson, R.J., 2008. Security Engineering: A Guide to Building Dependable Distributed Systems 2nd ed., Wiley.

Andrew, J.P. & Sirkin, H.L., 2007. Payback: Reaping the Rewards of Innovation 1st ed., Harvard Business School Press.

Atkinson, A.A. et al., 2007. Management Accounting 5th (2007) ed., Upper Saddle River: Pearson Education.

Baldwin, E.C., M, 2007. Managing IT Innovation for Business Value: Practical Strategies for IT & Business Managers: Practical Strategies for IT and Business Managers, INTEL PRESS.

Beer, S., 1994a. Brain of the Firm 2nd ed., John Wiley & Sons.

Beer, S., 1994b. The Heart of Enterprise New edition., John Wiley & Sons.

Bernard, S., A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.

Broadbent, M. & Kitzis, E., 2004. The New CIO Leader: Setting the Agenda and Delivering Results, Harvard Business School Press.
Brynjolfsson, E. & Saunders, A., 2009. Wired for Innovation: How Information Technology Is Reshaping the Economy, MIT Press.
Ciborra, C., 2004. The Labyrinths of Information: Challenging the Wisdom of Systems, OUP Oxford.
Dietz, J.L.G., 2006. Enterprise Ontology: Theory and Methodology, Springer.
Doucet, G. et al., 2009. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance, International Enterprise Architecture Institute.

Finkelstein, S., Harvey, C. & Lawton, T., 2006. Breakout Strategy: Meeting the Challenge of Double-Digit Growth, McGraw-Hill Professional.

Graves, T., 2008. Real Enterprise Architecture: Beyond IT to the Whole Enterprise, Tetradian Books.

Hoogervorst, J.A.P., 2009. Enterprise Governance and Enterprise Engineering, Springer.

Hoverstadt, P., 2008. Fractal Organization: Creating Sustainable Organizations with the Viable System Model, John Wiley & Sons.

Land, M.O. et al., 2008. Enterprise Architecture: Creating Value by Informed Governance, Springer.

Kaplan, R.S. & Norton, D.P., 2006. Alignment: How to Apply the Balanced Scorecard to Corporate Strategy illustrated edition., Harvard Business School Press.

Kaplan, R.S. & Norton, D.P., 2008. Execution Premium. Linking Strategy to Operations for Competitive Advantage, Harvard Business School Press.

Kaplan, R. & Atkinson, A.A., 1998. Advanced Management Accounting 3rd ed., Pearson Education.

Krafzig, D., Banke, K. & Slama, D., 2004. Enterprise SOA: Service Oriented Architecture Best Practices 1st ed., Prentice Hall.

Mintzberg, H., Ahlstrand, P.B. & Lampel, J.B., 2008. Strategy Safari: The Complete Guide Through the Wilds of Strategic Management 2nd ed., Financial Times/ Prentice Hall.

Potts, C., 2008. fruITion: Creating the Ultimate Corporate Strategy for Information Technology illustrated edition., Technics Publications, LLC.

Potts, C., 2010. RecrEAtion: Realizing the Extraordinary Contribution of Your Enterprise Architects, Technics Publications, LLC.

Prahalad, C.K. & Krishnan, M.S., 2008. The New Age of Innovation: Driving Cocreated Value Through Global Networks, McGraw-Hill Professional.
Rogers, E.M., 2003. Diffusion of Innovations 5th ed., Simon & Schuster International.

Ross, J.W., Weill, P. & Robertson, D.C., 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution illustrated edition., Harvard Business School Press.

Stamp, M., 2005. Information Security: Principles and Practice, WileyBlackwell.

Skarzynski, P. & Gibson, R., 2008. Innovation to the Core: A Blueprint for Transforming the Way Your Company Innovates illustrated edition., Harvard Business School Press.

Wagter, R. et al., 2005. Dynamic Enterprise Architecture: How to Make It Work 1st ed., Wiley.

Watkins, M.D., 2003. The First 90 Days: Critical Success Strategies for New Leaders at All Levels First Edition., Harvard Business School Press.

Weill, P. & Ross, J., 2009. IT Savvy: What Top Executives Must Know to Go from Pain to Gain, Harvard Business School Press.

Weill, P. & Ross, J.W., 2004. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press.

Weick, K.E., 2000. Making Sense of the Organization, WileyBlackwell.

Weick, K.E. & Sutcliffe, K.M., 2007. Managing the Unexpected: Resilient Performance in an Age of Uncertainty 2nd ed., Jossey Bass.

Woods, D. & Mattern, T., 2006. Enterprise SOA: Designing IT for Business Innovation 2nd ed., Sebastopol: O’Reilly Media, Inc.

Enterprise Architecture is more than IT

This blog post is based on the guest lecture that Chris Potts performed at the course B30 Enterprise Strategy, Business and Technology at the IT University of Copenhagen the 25th of October 2010.
It is growing sense around the world that Enterprise Architecture is dealing with more than IT; however since the concept’s origin from the world of IT has often been portrayed as an IT concept, and implemented as a rather IT centric tool.
Chris Potts asked the class at the lecture: “Can you recognize this architecture (this building – showing a picture of the insides of the Sydney opera house). This is a picture from the inside of the architecture. It proved to be the Sydney opera house but it is often hard to identify buildings (architectures) from the inside but it is rather easy to identify it from the outside”.
According to Potts is the biggest difference between an Enterprise Architect and a building’s architect, and that is “a building cannot change its own architecture” but an enterprise can, and Potts views on the definition of architects in enterprises deals mainly with that all the members in the enterprise in some way are architects. When it came to the role of Enterprise Architect is to change the world. Potts made use of the quotation below.
“According to Potts then Enterprise Architecture is about changing the world into something it probably wouldn’t otherwise have been.” – Chris Potts (2010b).
The question then becomes how to challenge the status quo, and the approach doesn’t always tells people what to do. So you may have an architecture but it doesn’t tell people what it is. According to Potts then sometimes the Enterprise Architect need to risk a lot as strategist and you would need to be ruthless.
Potts is of the opinion (an opinion he shares with Mintzberg and Ross & Weill) that strategy has to be embedded into the behavior of the actors within the enterprise. When it comes to behavior then there are two different forms that needs to be dealt with. The de facto behavior and the formalized behavior. The formalized approach to behavior deals with articulating the desired behavior in work structures through formalized descriptions of what is desired into the various artifacts.
When working with Enterprise Architecture then it might be a focus to use an argument as “Enhancing Enterprise Performance With Structural Innovations”. The hard part of this is the structural innovations part. The Enterprise Architect has to force himself to become innovative in using Enterprise Architecture and innovative in ways to improve the enterprise, and to create value for the enterprise as a whole.
“The whole is greater than the sum of its parts” – Aristole
Structural performance of the enterprise architecture is a principle that needs to be dealt with. Chris Potts mentioned that many investors work with analyzing the profits and costs of the enterprise but they usually fail with understanding or investigating if the enterprise is about to collapse from within due to bad architectural design.
There are many fundamental truths according to Potts. The first one is that the structural performance of an enterprise depends on its architecture, and the second one deals with an enterprise has an architecture regardless it is formalized or not.
The third truth that any enterprise architect should adapt is that the actual shape and structure of an enterprise’s architecture is the aggregated output of all its invests in change.
The fourth principle deals with the value of the structural innovation depends on the wider architectural context and last the enterprise architecture is about scenarios not certainties.
In this context the work with the core tactics is that the chief architect should bring both the explicit and implicit enterprise architects and make them work together.
Chris Potts introduced a new framework for change called the double e, double a journey.
Establish and explorer. These two steps are private to the chief architect and the activate and apply are public to the chief architect. It simply deals with taken over the enterprise through a guiding coalition which in principle can be related to the change framework that John P. Kotter who made the famous eight steps for change program (dating back to 1995).

The Scope of Enterprise Architecture was discussed and the class reached the following conclusions:
1. Activities and Processes.
2. Boundaries.
3. People.
4. Capabilities.
5. Resources.
6. Data.
7. Information.
8. Government and governance.
9. Environment.
10. Technology.
According to Potts markets do also have architectures and this approach leads to a fundamental focus on business architecture since the business architecture can’t stand alone to the market architecture. The market architecture contains the customer experience and from this perspective the architectures needs to be aligned to the market architecture to provide what the customers want. The business architecture in the other hand deals with the virtual organization (or more or less the virtual organization) and it is directly connected to the partners and suppliers that delivers materials and services to the enterprise.
According to Potts then structural performance is the key for measuring how well the enterprise is doing Enterprise Architecture. For this a cash-flow analysis based on the annual reports from the enterprise can be applied; however it is greatly encouraged to make use of other forms of analysis to come to this particular approach e.g., activity based costing. This approach might not give a correct view of status quo of the various lines of business and therefore other key performance indicators and methods needs to be applied.
Therefore should an Enterprise Architect make use of context specific strategies for each line of business. The example that Chris Potts made use of was a bit simplified in relation to measuring the different initiatives the enterprise works with; however it is a needed technology.
Chris Potts emphasize that the politics of management and the politics of organization is of great importance when it comes to Enterprise Architecture, and if the chief architect doesn’t understand the dialectic struggle within the enterprise then it certainly will become a problem for implementing Enterprise Architecture, and according to Potts the political aspect of governance is rather often worse in the public sector than it the private sector.
The interesting part about the approach that Potts makes use of is that he actively tries to describe how a chief enterprise architect has to be able to play many roles and he has to be able to facilitate innovation and development issues within both the lines of business and enable the top management of the enterprise to govern the various lines of business. In other words he has to be able to facilitate innovation while tightening control which usually is a contradiction.