8 years, 7 months ago

Key SOA Governance Considerations – Part 4

So far the articles 1, 2 and 3 in the series have addressed the SOA governance aspects such as, understanding the context, defining the objectives and parameters, understanding various components such as timing and artefacts to govern, roles and respo…

8 years, 7 months ago

Enterprise Architecture – Wikipedia

I was looking at the Wikipedia entry for EA and found this chart which does a great job showing the differences of ENTERPRISE Architecture vs. SOLUTION Architecture across several categories.  This really gets at the heart of a misconception many peop…

8 years, 7 months ago

Managing MSIT’s Enterprise Platform Portfolio

I have the fortunate opportunity to manage the Enterprise Platform portfolio for Microsoft IT and thought that I’d share some tidbits how I do it.

In Microsoft IT, the Enterprise Platform Portfolio (EPP) is only one program portfolio peer to other program portfolios like our Line-of-Business (LoB) specific portfolios such as Sales, Marketing, Services, HR, Legal, IT (yes, even IT is a LoB to us), etc. The EPP is a portfolio designed to manage our platform systems and encourage them to deliver more value to the company.

I’ve distilled the EPP’s Charter (aka Team Model, Process Model and Delivery Approach) into the following points to help articulate how I manage the EPP:

  1. Fund Platforms only. It seems simple enough, but defining what is a Platform and what isn’t like Application, Vendor Products, Processes, Capabilities, Locations, etc can be a bit tricky. We pulled our definitions from our Enterprise Information Model and elaborated on them to help communicate what qualifies for funding from the EPP and what doesn’t. We use a couple of views, one that is more loose and one more explicit to help communicate to different audiences. Here are a couple of diagrams that we use:

      Architecturally-pure Platform Diagram Exec-ready Platform Diagram 
      Enterprise Platform Definition 1 Enterprise Platform Definition 2

            • An Enterprise Platform is a set of Components where one or more of those Components are used by more than one Application. More than one Line of Business uses these Applications.

            • An Enterprise Platform may master a Data Facet.

        • Fund non-discretionary costs first, then allocate the remaining budget based on criteria intentionally used for the Platform to deliver business value. Here is our prioritization criteria as a reference:

            Business Alignment


            Relation to Goal Prioritization

            Does the Platform relate to highest priority Business Goals?


            Capability Assessment

            Does the Platform relate to priority Business Capabilities Assessment (Value, Performance and Maturity)


            Business on-boarding Commitment

            Can the Platform demonstrate commitment from multiple businesses?

            Portfolio Simplification  

            # of Redundant Apps and Plats

            • Will the Platform reduce redundant Applications/Platforms?

            • Will the Platform retire similar functioning Applications/Platforms slated for retirement?


            Retirement of Unsupported Vendor Products

            Will the Platform retire the use of unsupported vendor products?

            Platform Excellence


            Information Quality

            Will the Platform improve information quality; make information more accurate and available?


            Regulatory Compliance

            Will the Platform help Microsoft comply with Regulatory Compliance?


            Security and Privacy Policy Alignment

            Does the Platform comply with Security and Privacy Policies?


            Flexibility, Maintainability

            • Flexibility to support many Business Processes

            • Self-service

        • Solicit senior Architects to form a role-based Team Model. I’ve created a Team Model with 5 voting members filled by Microsoft IT’s most senior Architects. Each advocate 5 different perspectives of our Platforms investments; Business Advocate, Enterprise Architecture Advocate, Technology Use and Incubation Advocate, Platform Software Quality Advocate, Operations Advocate. It’s important not to make this team model reflective of the organizational team model but rather a set of perspectives of a platform. This avoids the situation of having organizational-bias in the voting and commentary of Programs in the Portfolio.
        • Platform Roadmaps. We use Platform Roadmaps to document what the Platform will do. The entities on a Platform Roadmap mirror the information in our Prioritization Criteria. That is, a Platform Roadmap includes all associated Business Goals related to the Program affecting the Platform, Business Capabilities and Process Flows improved, Applications and Platforms that will be retired as a result of the Platform, supporting Vendor Products, etc. We equate Platform Roadmaps to a sort of contract or agreement that the Program must adhere to. During the Program’s delivery, we run current Program information and compare it to the Roadmap to determine we the Program is on-plan or not. From the EPP’s perspective, the Platform Roadmap is the scope of the Program.
        • Enterprise Architecture to manage the EPP. Managing the EPP is the responsibility of our Enterprise Architecture team. This is important because the Platforms are an enterprise concern and require skills plus organization position to perform the necessary analysis to optimize our platform portfolio. For example, we perform analysis to form our Platform Strategy that includes cross-LoB needs analysis, associations to our enterprise data facets, application and platform consolidation methods, vendor products analysis to optimize our licensing and support contracts. Also, being positioned outside of the typical IT value chain (LoB-facing resources, engineering/development, and support) allows us to easily traverse the organization and remove organizational bias.
        • Data-driven funding allocation process flow to balance the portfolio. I’ve put together a relatively simple funding allocation process flow which allocates funding to Programs via decision points. For example, if a Program is in-flight, we allocate funds to ensure its original scope is delivered. If a Program requires funding to become compliant, we allocate compliance funds. One thing that we do to help spread the funds so that we don’t find ourselves shoveling all our available funds into one or two programs is utilize the concept of ‘seed’ funding. Seed funding is a limited amount of funds to allow a team to prove themselves per our Prioritization Criteria listed above. In our situation, we have some platforms that veer off-plan, therefore, score low on our Prioritization Criteria. In these situations, we limit funding to simply allocating non-discretionary funding and then seed fund them to get them back on track. This allows us to spread the funds further and fund new Programs and course-correct existing Platforms. Our customers perceive this as IT being more agile to changing business needs. For our funding allocation process flow to work, we must make the decisions data-driven to remove opinion and bias as much as possible. This is where my senior architects come into play. That is, they vote Y/N on each Prioritization Criteria for each Program. Those that rank higher are pushed through the funding allocation process first. We iterate through the funding allocation process flow until all available budget is allocated. Then draw the line leaving us with a list of which Programs are funded, what scope is being funded.
        • Continuously invest in Portfolio Management maturity. There are always improvements to ensure the platform portfolio is managed to deliver the most business value possible. The more mature the portfolio management, the more business value realized. Capabilities such as:

          • Portfolio Optimization in terms of
            • Program Dependency Analysis to understand when Programs can be hydrated to optimize resource allocation.
            • Program Overlaps and suggestions for what should happen to them.
            • Platform Strategy to understand where we want Platforms to go directionally and how to get there via promotion of Applications, retirement of Applications and Platforms, etc
            • Program Gaps to be filled as a results of analysis of Business Strategy
          • Strengthening the Portfolio Management Team to sit on funded Program Teams to guide and ensure delivery to stated Platform Roadmaps
          • General continuous improvement

        I’m curious to learn what others do to manage platforms. Please share your thoughts if you have a moment.

        Categories Uncategorized
        8 years, 7 months ago

        A Good Cloud and A Bad Cloud…

        An interesting time to write about cloud, what with the ash cloud from Iceland volcano grounding air travel in and out of Europe to complete halt. Usually the views from my office window are dominated by planes which are either taking-off or landing at…

        8 years, 7 months ago

        Paradoxes in EA and Systems Research

        In my ongoing research, I have identified a close link between enterprise architecture/engineering and systems science. P. Harmon, the prominent business process thinker and author of the book Business Process Change (K. Harmon 2007), Hoogervorst (2009…

        8 years, 7 months ago

        Paradoxes in EA and Systems Research

        In my ongoing research, I have identified a close link between enterprise architecture/engineering and systems science. P. Harmon, the prominent business process thinker and author of the book Business Process Change (K. Harmon 2007), Hoogervorst (2009), and Dietz et al. (2008) all discuss the influence of systems science and systems thinking on the process management and enterprise engineering disciplines as such, whilst K. Harmon (2005) even stresses the contention that systems thinking is a basic premise for the successful IT/management strategy implementations in today’s organisations. Interestingly, these authors share the same foundations of research: cybernetics and systems thinking as put forward by Norbert Wiener (1948) and Ludwig von Bertalanffy (1969) — and for Dietz and K. Harmon, R. L. Ackoff (1981, 1993).

        Obviously, systems science and cybernetics has offered very important contributions to IS research — especially within process management where organisations are better conceived as self-regulating, self-controlling systems rather than Laplacian machines that reason and act only by their internal causal structures. Systems researchers such as Beer, Bertalanffy, Ackoff, and Checkland have all contributed towards making this a mainstream research branch within a multitude of sciences, and it has also found its way to the enterprise engineering. But K. Harmon’s integration of enterprise architecture research and systems thinking is a good example of cybernetics as a research eulogy: we have finally found the magic gemstone that bridges the gap between our IT systems and business operations. 

        Unsurprisingly, that wide statement come at the cost of certain ontological premises. In my thesis research, I have made an attempt at systematizing these premises and their ontological influences on enterprise architecture. The criticism might not be unique or new, but at least it is an attempt to put very important research in the broad frames of enterprise architecture. We keep stating that EA is the future meta discipline for the modern enterprise; thus we also need a broad meta framework that is capable of 1) questioning its own foundation and 2) supporting the diverse types of knowledge, processes, and methodologies within an organisation in order to create and sustain innovation. In my next blog entries, I will present these critique points, and hopefully receive some valuable feedback as well. I haven’t been very good at replying to your valuable comments; that is only due to me being busy, and not because of arrogance or ignorance. I will post a follow up very soon. 

        Defining Cybernetics
        Before I present the initial critique, it is valuable to define what cybernetics really is, and how it relates to systems thinking. Both disciplines are often used interchangeably, but there are, depending on the author, certain differences. 
        Systems theory and Norbert Wiener’s theory of cybernetics are closely related (Heylighen 1999). But where systems theory focuses mainly on the structure of systems, cybernetics concerns the function of a system (e.g. what the system does) in relation to other systems. But, as Heylighen puts forward in Principia Cybernetica, both concepts are facets of the same subject and have permeated into a vast amount of sciences from information systems and biology to social sciences (ibid.). To provide a comprehensive analysis of EA and systems thinking, it is thus also necessary to draw in cybernetics.
        The word cybernetics stems from the Greek word kybernetes meaning pilot or steersman and was by one its pioneers, Norbert Wiener, defined as the science encompassing “the entire field of control an communication theory, wether in the machine or in the animal.” (Principia Cybernetica: Defining ‘Cybernetics’ – http://www.asc-cybernetics.org/foundations/definitions.htm — accessed on Apr 11 2010). However, that is only one branch of a definitional wilderness, spanning from Bateson’s very rigid explanation of cybernetics as “a branch of mathematics dealing with problems of control, recursiveness, and information” (ibid.) through Humberto Maturana’s very broad definition of cybernetics as “The Art and Science of Human Understanding. (…) Why? The Person that guides the ship, the skipper, acts both on practical know-how and intuition. Thus, the skipper acts both as a scientist and as an artist,” (ibid.) – and finally to Heinz von Foerster’s very cryptic conceptualisation: “Should one name one central concept, a first principle, of cybernetics, it would be circularity.” (Ibid.)
        Concluding on the previous analysis of systems thinking within EA, it is tempting to assume that a systems theoretical foundation for EA is less mechanistic and more nuanced in its conceptualisation of knowledge and organisations. But, in my opinion, that assumption is flawed.

        Paradox no. 1: The Enterprise is a System v. The Enterprise as a System
        Systems science, as put forward by the authors previously mentioned, operates on the basic assumption that an enterprise is a system, and therefore one must frame it as a system in order to manage it efficiently[1]. But this “systemification” of organisation theory is just as reductionistic and mechanistic as orthodox Cartesian thinking: if we invert the implication, we are logically forced to accept the inference that if the subject matter of interest is not a system, it is not an enterprise. Operating from that premise automatically constrains our framing of organisations in another way and thus entails a new systemic reductionism in the EA discipline. There is a fundamental difference between postulating that enterprises carry systemic properties, behave like systems, or should be interpreted or framed as systems, since the conceptualisation here occurs at the epistemological level (how the knowledge about the subject matter is produced), rather than stating that the subject matter inherently is a system in its own right (which thus occurs on the ontological level — this entails that the fundamental nature of reality or reality is essentially constituted by systems). The words ‘is’ or ‘behaves like’ make a very distinct — and crucially important! — difference.
        Accordingly, the philosophical underpinnings of the notion that an enterprise is a system – and, as articulated by Bertalanffy, is best framed as a biological system or organism — are questioned by Kast and Rosenzweig (1972): 

        “One of the basic contributions of general systems theory was the rejection of the traditional closed-system or mechanistic view of social organizations. But, did general systems theory free us from this constraint only to impose another, less obvious one?” (Kast et al. 1972) 

        Here the authors draw in Daniel Katz and Robert Kahn, who criticise the organismic perception of organisations (1966):

        “The biological metaphor, with its crude comparisons of the physical parts of the body to the parts of the social system, has been replaced by more subtle, but equally misleading analogies between biological and social functioning. This figurative type of thinking ignores the essential difference between the socially contrived nature of social systems and the physical structure of the machine or the human organism. So as long as writers are committed to a theoretical framework based upon the physical model, they will miss the essential social-psychological facts of the highly variable, loosely articulated character of the social system” (Katz and Kahn, 1966, p. 31, my emphasis)

        Both sources clearly underline the problems of the systems (or first order cybernetic) approach to organisations and EA: the baseline assumption that an enterprise is a system and that this system behaves like an organism (rather than like a predictable machine) is fallible and just as reductionistic and mechanistic as the Machine Age thinking introduced by Ackoff (1981).


        [1] An example thereof: Dietz writes, “As said before, the basic premise of enterprise engineering is that an enterprise is a designed system” (Dietz et al. 2008, p. 573), and supports that contention by stating: “The most important premise in the notion of Enterprise Engineering is that an enterprise is a designed system instead of an organically growing entity.” (ibid. p. 578) Similarly, K. Harmon equals enterprises and systems by stating that “frameworks and methodologies used in the development of enterprise architecture should, and in time will, more clearly demonstrate that an enterprise is an intelligent complex adaptive system of systems” (K. Harmon 2005 p. 3).

        Ackoff 1981: Creating the Corporate Future: Plan or be Planned For — Ackoff, R. L., Wiley, 1981.
        Ackoff 1993: Beyond Total Quality Management. High profile lecture. University of Hull, 18 September 1993.
        Bertalanffy 1969: Bertalanffy, L. von, General Systems Theory, New York, George Braziller 1969.
        Dietz et al. 2008: Enterprise Ontology in Enterprise Engineering — Dietz, J. L. G and Hoogervorst, J. A. P. – Proceedings of the 2008 ACM symposium on Applied computing — ACM.
        K. Harmon 2005; , “The “systems” nature of enterprise architecture,” Systems, Man and Cybernetics, 2005 IEEE International Conference on , vol.1, no., pp. 78- 85 Vol. 1, 10-12 Oct. 2005.
        P. Harmon 2007: Business Process Change, 2nd edition, Morgan Kaufmann Publishers, 2007. 
        Heylighen et al 1999: Principia Cybernetica: What is Cybernetics and Systems Science? – F. Heylighen, C. Joslyn, V. Turchin 1999 – http://pespmc1.vub.ac.be/CYBSWHAT.HTML (Accessed on Apr 3 2010).
        Hoogervorst 2009: Enterprise Governance and Enterprise Engineering, J. A. P. Hoogervorst, Springer 2009. 
        Kast et al. 1972: General Systems Theory: Applications for Organization and Management – The Aaademy of Management Journal, Vol. 15. , No. 4, General Systems Theory (Dec. 1972) pp. 447-465, Fremont E. Kast and James E. Rosenzweig, publ. by the Academy of Management.
        Katz and Kahn 1962: The Social Psychology of Organizations – Katz, Daniel and Robert L. Kahn, New York: John Wiley and Sons, Inc. 1966).
        Wiener 1948: 

        Cybernetics: Or Control and Communication in the Animal and the Machine. Wiener, N. Paris, France: Librairie Hermann & Cie, and Cambridge, MA: MIT Press.Cambridge, MA: MIT Press.

        8 years, 7 months ago

        Paradoxes in EA and Systems Research

        In my ongoing research, I have identified a close link between enterprise architecture/engineering and systems science. P. Harmon, the prominent business process thinker and author of the book Business Process Change (K. Harmon 2007), Hoogervorst (2009…

        Categories Uncategorized
        8 years, 7 months ago

        EA Summit Las Vegas – Day Three

        We’ve just wrapped up the EA Summit in Las Vegas and it seems to have been a very positive experience for everyone. The Gartner analysts and our case study speakers were very happy with the level of sophistication of the audience – great questions, comments and challenges.  Many attendees had positive comments on both the […]

        The post EA Summit Las Vegas – Day Three appeared first on Brian Burke.

        8 years, 7 months ago

        EA Summit Las Vegas – Day Three

        We’ve just wrapped up the EA Summit in Las Vegas and it seems to have been a very positive experience for everyone. The Gartner analysts and our case study speakers were very happy with the level of sophistication of the audience – great questions, comments and challenges.  Many attendees had positive comments on both the […]