Tuesday, December 14, 2010

Market-Driven Enterprise Architecture Research Finale

Dear all participants in the MDEA survey 2010,
The research has come to an end, at least for now.

Thank you all for taking time to contribute. Thanks also to Stan Slater, and George S. Day - Experts in Market Orientation. And to Scott Bernard, and EAdirection's Tim Westbrock and George Paras  - Experts in EA. And to Dr. April Cantwell, Industrial Psychologist. And thanks to John Goetze, Chief Editor at Journal of Enterprise Architecture,  and Dr. Linden Brown, Chairman of MarketCulture Strategies Inc, for lengthy discussions.

As promised I will share the findings. In their present form they're hardly a quick read (147 pages), however feel free to write me if you would like the full work (participants in the MDEA survey who's indicated they would like a copy will receive an email from me with a link). It shouldn't be too far into the future before I get to skin down the report to a more digestible format either...

Here's a few excerpts:

Model of Market-Driven Enterprise Architecture
Initial model developed theoretically and discussed with select experts for nuances and face validity, resulting in the following model of MDEA.





MDEA Measurement Scale
The MDEA model was developed into a measurement tool consisting of seven dimensions and a total of 35 items.

MDEA Measurement Scales


MDEA Survey
EA practitioners worldwide were invited to complete a survey to collect data on the presence of MDEA behaviors in EA practices. The following are some of the demographics - Click to enlarge

Countries
Years of EA
EA role

With the participating sample, the MDEA scales were found to be both reliable and valid. As a biproduct, a benchmark was developed to compare performance across countries.

Percentile rankings of represented countries on the MDEA scales and performance


MDEA and Business Performance link
Using subjective measures of performance, the MDEA scale was found to significantly (99.9%) account for 30% of the variance in reported performance. Hence, EA practices performing well on the MDEA scales are likely to lead to better business performance than practices that are not.

To be continued...
The findings are not naively trying to depict the model that will generalize across all contexts. It doesn't claim to be the right way of doing EA either, if there is such, for that it is far too premature and limited in operational detail. However, it does present a logically derived framework, which is neither MO nor EA alone, but both in an integrated and coherent view on the organization. As such business leaders, managers, EA practitioners, ...,  may find the framework helpful in building bridges between what has previously not been integrated well, including the integration with the cultural side of the business. And integration is highly important....

The findings lend themselves to be explored further in research, to be continued in whatever way. By case studies, by additional confirmatory studies across more variables such as market volatility, political economic environment, national cultures, etc etc. Please be free to submit your critique too.

--- Let me know if you have any questions here, and if you would like to see the full report.

Friday, July 23, 2010

Are you an Enterprise Architect? Please help the discipline...

Dear Enterprise Architects... Your help is needed.

This is a new look at the EA discipline, searching out how attuned we are to the needs of our businesses, and how well we understand ourselves as part of the business context.
It's a merger between Market Orientation and Enterprise Architecture, two separate disciplines who's individually been proven to impact business performance, significantly.

This is a survey.... STOP! Stay here... Please... This is a new survey, which seeks to answer how much we really live what we preach. How much do we listen to the business. How much are we part of the enterprise context, and not separate from it. And how much can this be seen on the bottom line of our businesses.

The Plea
Dear Enterprise Architect, please invest the 15 minutes it takes to participate in this survey. In return you will receive a report that details the findings, provided you enter your contact details after submitting your response.


## - Access Survey Here - ##


If you submit your Twitter ID too, I will broadcast your contribution as well.

Please help the EA discipline... Take this survey. And share it with your EA colleagues.
Your contribution is very valuable.

Sunday, July 18, 2010

Outside-In discussion on LinkedIn (EA Connections)

Here a portion of a discussion I've been running in a LinkedIn group (EA Connections) . Thought it may be of interest.

@Anand & @John - Interesting insights added on HPC. @John - I agree there's certainly an element in Outside-In EA that is to strike the right balance between IT and business, in any EA for that matter. No matter how much we push EA to truly be a holistic enterprise discipline, and not only IT, we shouldn't forget the strength that lies in the IT legacy. EA has the potential to fully leverage technology advancements and make sure they work perfectly with the rest of the enterprise system.

@Steve - thanks for this valuable contribution. The way you build up the EA scenarios is spot on I think. I am working in much the same framework and is currently doing research right in the heart of your scenario 4. Based on discussions with thought leaders in both the fields of Market Orientation and Enterprise Architecture, I have ended up in a three dimensional model I call Market-Driven Enterprise Architecture. I will be happy to share this some time soon. What I may get to do in this network first though, is to invite the EA professionals in here to participate in a survey, which is a step in my research. I hope to have it out early next week.

But to share some of my preliminary thoughts, describing just a few of the key dimensions as I see them:

1) The enterprise exists in an expanded periphery, incl. the customer context, competitive context, regulatory context, and value network context. Without a sense of the enterprise as part of this larger picture, the perception of the enterprise in which we're working to make advancements is misconstrued, and so will be the initiatives we undertake.

2) To the point above, an enterprise can be more or less connected with its expanded periphery. EA has traditionally been good at providing solutions to this in the IT domain, equipping the enterprise with information systems and working to scale opportunities for integration and information leverage across the business. But a significant portion of the enterprise connection to the expanded periphery is through a cultural element. This is, how well does employees live norms and values that are centered around creation of customer value, both to internal and external customers, and do they too understand the competitive space that can influence the value creation. I see the entire enterprise ideally being wrapped in a homogeneous culture membrane that makes the organization distinct from its environment, and in this culture are embedded important drivers of outside-in thinking.

Even though EA has acknowledged the culture side of the business, it's typically in the sense of how the culture affects the ability of EA to be successful in the business. I think there's great potential for EA to work actively in the culture space, by defining desired culture attributes and artifacts in the enterprise-wide context, which, of course, would fit in the overall architecture. @John - This is another area where EA needs to strike a balance, and actually has the potential to do it well.

3) A handful of other elements deals with alignment. This is, strategic alignment, operational alignment, and horizontal alignment or cross-functional coordination.These are attributes that lend themselves to the architecture discipline, but they need to be driven not out of IT necessarily, rather what is of essence to the organization of the enterprise, given its specific market context and strategic needs. There is a hierarchy to this, which I call Strategy & Leadership->Business Operating Logic->Operating Capabilities. You can easily map this hierarchy up against any traditional EA stack.

Just to mention some core elements of the way I look at this.
Again, I am doing research that goes deeper into this. If you wish to participate, please let me know. Any comments here are of much value too.

Saturday, June 5, 2010

Fear of Complexity and the Ontology/Epistemology of EA

Last week I had the pleasure of speaking at the Carnegie Mellon University EA Certification program in Denmark, delivered by the EA Fellows. The invitation was to speak about the Market Coherent Enterprise topic (see the presentation here). I went to the venue early and joined part of the general curriculum discussion, and with my topic at the top of mind a few perspectives stuck with me:
  1. Fear of complexity. The notion was that the more we ask of EA to accomplish, the less likely are we to achieve something of significance (this is not a direct quote, but my own interpretation of a few comments carrying this meaning).
  2. Need for EA to include "people". There was a general consensus, it seemed, that EA should be better at dealing with, or even be including, the people side of the business. 
These two perspectives represent somewhat of a wicked problem. They're somewhat contradictory. Yet, they're both very valid. And if not yet proven valid in a scientific sense, they sure still remain legitimate, simply by the fact that they had been identified by a mix of qualified EA practitioners, pragmatic implementers alongside meta-level strategists. Since these are indeed complex problems, I'll simply discuss them superficially in the following. Hopefully we can get to spend the time they deserve at a later point in time.

Fear of Complexity
On the surface this resembles the universal challenge we face when deciding scope for any type of project, program, portfolio, strategic direction, etc.  If we bite of too much, we may be spreading our resources too thin, goals may become diluted or even incommensurable. Complexity gets in the way of staying on target. Communication fails, because we're communicating too many messages, or we may not communicate at all because we're not sure what to communicate and we end up stalling.

Naturally, if we add a significant people-dimension to the current EA practice we also add complexity. And this begs the question: By adding a deeper people capability, do the benefits outweigh the risks of expanding the scope? This is something that must be assessed by the individual EA effort, but in my mind there's a question that needs to be asked before anything else: By adding a deeper people-capability, does the EA effort stay the same and continue on its existing path, or does it need an all-round new face and agenda in the organization? It ties into the inside-out/outside-in discussion. What should be the ontology of EA...

Clearly, there are other dimensions to the complexity that are added here. One of the foremost challenges of the EA domain has been to win significant attention and buy-in from the top leadership. So, when adding a people dimension, how does this change the way the EA practice is "sold in" to the organization. On a side-note, I think this question comes close to the essence of the fear noted at the EA certification program. I have no answer to this, but two things I think need to be perennial for anybody seeking an answer are these:
  1. Do not be locked into a single paradigm for how EA is to be applied. Consider whether there are different and better ways. Ways that would be right for your organization.
  2. Consider the customer in the equation. The full breadth of them including your's internally, but primarily the end-customer(s) of the business.
I am a strong believer in the fact that complexity, or perceived complexity, is a byproduct of not having foundational questions like these to return to. When complexity becomes an enemy there is no better way than to go back to basics.
    Need for EA to include "people"

    I have touched on this in previous posts and I will not spend time here advocating for the people inclusion. Rather, I want to simply illustrate that the people dimension is indeed on the radar out there among practitioners, and that it's more than simply discussing how our EA efforts interface with a people dimension.
      
    For example, an exact criticism at the CMU course was targeted the way Scott Bernard's EA3 Cube (picture to the right) mentions workforce only as a "common thread" in line with security and standards. This may have been a slightly unsubstantiated criticism, but nevertheless it captures the mindset that was shared among these EA professionals in Denmark. Workforce or Human Resources are much more essential to our design and execution of EA efforts than they can be left to be considered a peripheral element to be dealt with. Instead, EA should be taking a proactive role in shaping how the workforce exists as part of the architecture, not how it interacts with the architecture.

    Forgive me for going into this, but for illustrative purposes, this is almost like the twist between the early and the late Wittgenstein. The early Wittgenstein, part of the school of logical positivism, advocated that we can stand outside the language we use, and that a single standard language could be used to codify all knowledge. To me this is very much like the way EA is currently applying itself in organizations. We codify knowledge with artifacts, the standard language, and make it accessible in a repository to guide future knowledge creation. In the same school, Wittgenstein also said something in effect to "Of what we can't speak (with the standard language) we shouldn't speak of at all (such as metaphysics). However, as Wittgenstein's philosophy matured, he realized that the devotion to the pure standard language meant missing out on some of the things that humans still tend to speak of, such as metaphysics. In the late Wittgenstein, language instead becomes a like a cheese bell, in which we sit inside and only can comprehend things as they appear to us through the glass. The language we use is our reality.

    In a similar fashion, the way I see it, Enterprise Architecture must not be approached as something that can stand outside the organization or be rationally constructing it. EA is very much part of the organization and its culture, and EA must be dealing with people accordingly - including ourselves as leaders, architects, managers, change agents, and employees.

    Friday, May 21, 2010

    Principles for Market Driven Enterprise Architecture

    "Outside-In" or "Inside-Out"?

    In my previous blog post I stressed that a market approach to the organization must come before an EA approach. Obviously, there is a conflict of words here, if we approach Enterprise Architecture as a holistic discipline to map the enterprise. A holistic perspective would by nature be all-encompassing, and thus also be accommodating of the enterprise's interface with the market. Nothing in that sense would then come before EA. But if we, just for now, take the traditional approach to EA, the one that is heavy on IT, and aligns IT to the business, then a Market Orientation would come before an EA.

    Unfortunately, we have a way of looking at the enterprise "system" in a two-dimensional way. And that potentially hurts our perception, I state, just as much as were we looking through a prism. Even though we occasionally see a cube or a z-axis-diagram, it's very difficult to capture the essence of our enterprise-systems in these illustrations and we fall back on 2D-views. The illustrations are what they are: appropriate tools to visualize something complex and help us draw out interrelationships - but while we illustrate and read these diagrams I urge that we at least continue to think of the enterprise as multi-dimensional.

    So - thinking of the enterprise as multi-dimensional:
    Do we adapt to our surroundings from within, from the "inside-out", where there is little and blurred visual of the surrounding impulses, or do we strive to connect with impulses in a way that is as close as possible to "outside-in"?

    I would personally go with the outside-in. And it is the outside-in paradigm that drives me to say that Market Orientation comes before EA. Our understanding of market impulses and what impulses are important is a prerequisite to effectively coordinate a response to those impulses. Or a co-existence with those impulses. Or a co-creation with those impulses. Thus, when stepping back into the 2D world, Market Intelligence along with our knowledge of how to strategically exist in the market, are the two foremost drivers of how we choose to do business, how we choose to coordinate our business, and how we prioritize change in our business.
    Market Drivers and the Strategic Driver derivatives are at the top of the hierarchy. These together form the guiding northern star.

    Market-Driven Enterprise Architecture

    I've just been reading in Weill and Ross' (2009) excellent book "IT Savvy".
    Although IT is central as an enabler, and the whole digitized platform is very central, there's a clear market-driven nature of the IT Savvy firm arising between the lines. For example, the 5-year, heavily profitability-boosting, turnaround of the U.S. health care service giant Aetna was attributed to:
    1. Intense focus on customers and employees
    2. Company-wide embrace of "back to basics" values
    3. Development and use of a dynamic IT platform.
    Several of the great IT Savvy examples mentioned in the book evolve around an understanding of customers needs and how to serve those needs better. How business processes have been defined or redefined to meet customer and market demands. Similarly, it also illustrates how poor business process and systems designs can be significant inhibitors to creating customer value, i.e. by forcing employees to work around, or compensate, for disjointed systems and processes (Weill & Ross, 2009). The book is not shy either to use terms such as customer alignment and customer responsiveness.

    And then comes the choice of an Operating Model. A model that is to influence all decisions downwards in the hierarchy. Four combinations of Business Process Standardization and Business Process Integration: Coordination, Diversification, Replication and Unification. Depending on complexity, these can be enterprise-wide, individual for different lines of business, or both. The direction is very much top-down: Market Alignment drives Operating Model - Operating Model drives Business Processes - and Business Processes drive Digital Platform Requirements. It's not the other way around. And there's no talk about aligning IT to business either. Rather, Business dictates IT.

    Although there's no talk as such about Enterprise Architecture in "IT Savvy", it does, between the lines, set up some premises and principles for applying EA. It speaks to the benefits of having an EA discipline, but it also makes clear that EA is an enabler of something larger - it's not a driver, but a follower and a coordinator.

    Inspired by the premises set forth by Weill & Ross (2009), I've collected some thoughts in the below chart on what the hierarchy of drivers and enablers would look like in the Market Coherent Enterprise (click to enlarge).


    I will let this chart sit without explanation for a bit....

    When reading the chart - What do you see? What challenges come to mind?

    References:
    Weill & Ross (2009). IT Savvy - What Top Executives Must Know to Go from Pain to Gain. Harvard Business Press. Boston, Massachusetts.

    Recommended Readings

    Saturday, May 15, 2010

    Strategy for the Market Coherent Enterprise

    The All Important Strategies And The Choices We Make ....
    In pursuit of the Market Coherent Enterprise by cross-fertilizing Market Orientation with Enterprise Architecture, the external connectedness paired with the internal connectedness, one of the most important questions arising is from my perspective the strategy choices we make at 1) the offset of such a journey and 2) continuously. I wouldn't frame it as the strategic impact the fertilization has on the organization, but rather the impact our strategic choices have on the these critical external and internal coherency dimensions and our ability to succeed with them and make them work to our competitive advantage.

    Operational Effectiveness Is Not Strategy
    To elaborate what I mean by the above I want to discuss the strategy concept briefly. In a well-known article by Michael E. Porter (1996) - "What Is Strategy?" he touches on some of these issues. First, three key principles of strategy are outlined:
    1. Strategy is the creation of a unique and valuable position, involving a different set of activities
    2. Strategy requires you to make trade-offs in competing - to choose what not to do.
    3. Strategy involves creating "fit" among a company's activities
    There are a myriad of strategy combinations arising from these principles. Some are appropriate for some businesses, some markets, some types of customer-competitor-channel-offline-online-onshore-offshore-resource-based-knowledge-based constellations. It doesn't really matter. The bottom line is that a lot of the so-called strategies pursued by businesses to gain competitive advantage are not generating a long-term return, and in the midst of pursuing them, I advocate, a business easily loose sight of the essential and quite simple arithmetic of sustained profitability: It must deliver [continued] greater value to customers or create comparable value at a lower cost, or do both. Value allows higher unit prices, efficiency lower unit costs (Porter 1996).

    But for sustained competitive advantage a business must be able to preserve its position. Efficiency is imitable, always. Customer value is imitable, sometimes. Porter argues that the lowest denominator in competitive advantage are activities. It all comes down to the activities required to produce, sell or deliver products or services (... and service customers I would include). Cost is generated by performing activities and cost advantage arises from performing activities more efficiently than competitors. Operational effectiveness is performing activities better than rivals, which may or may not include performing them more efficiently too. In contrast, strategic positioning means performing different activities than rivals or performing similar activities in different ways.

    So what does this tell us?

    Enterprise Architecture can help us perform activities both more efficiently and effectively, and that can give us a short-term competitive advantage. EA may even help us in our strategic positioning, by proposing pathways to differentiate (I hesitate to say "using IT as differentiator" because I still want us to look at EA holistically), but this too is imitable. So EA in and by itself is not worthy as a strategy. In fact, I argue that having EA as an informant to strategy introduces a critical risk to our market connectedness simply by the fact that it is rooted in how we operate, rather than why we operate. It is an inside-out approach, rather than an outside-in approach.

    Market Connectedness and Strategy comes before EA and Strategy
    EA can be seen as a strategy execution mechanism (Saha 2009), and this may direct the way EA is applied in businesses. On this basis Saha (2009) has introduced four design models for EA, coming to existence in a matrix form based on two continuum: 1) an EA Value Proposition, which goes towards either standardization or differentiation, and 2) an EA Emphasis, which is placed somewhere between business and technology. The matrix they form looks as follows:


    Picture source: Saha (2009) - International EA Conference of the Danish IT Society. Copenhagen, Denmark. September 17 – 18, 2009

    Now, these design models are not suggested as business strategies, but I will argue that the archetypes of strategies they lean against represent demarcations that could potentially misguide the businesses they are applied within, if they are in fact taken on as general strategic models, and EA is applied as the primary driver for pursuing them. Unfortunately I haven't yet had the opportunity to read Ross, Weill and Robertson (2006) - Enterprise Architecture As Strategy, but it should arrive on Tuesday and I will follow up on this again shortly after...


    What I am getting at is this: In the fertilization of Market Orientation and Enterprise Architecture, MO represents the part of the business that has to do with superior customer value, and EA would mostly be concerned with how to operationalize this in a way that leverages the full potential of the market connectedness. EA would lead the internal coordination, alignment and utilization of information, which is a really important role. EA would be the enabler and the controller for most of the essential interfaces in our businesses, interfaces that can lead to employees either making value-creating decisions, or value-destroying decisions, whether we perform value-creating activities or value-destroying activities. But nevertheless, EA would still be a servant of the key focus: to deliver greater value to customers or create comparable value at a lower cost, or do both. (recall this from Porter?). 

    Thus, in the fertilization of MO and EA, MO comes before EA. And MO will get the first hand right to inform strategy and what activities to perform in our value chain. EA, on the other hand, is an all important aspect of bringing life to our strategic decisions, linking everything together in a coherent network, and in enabling the enterprise to continuously learn and adapt. 
     
    References:
    Porter, Michael E. (1996). What is Strategy? Harvard Business Review. November-December 1996.
    Saha, Doucet. et al. (2009). Coherency Management: Architecting  the Enterprise for Alignment, Agility and Assurance. Chapter 2. The Four Design Models of Enterprise Architecture. AuthorHouse.
    Saha (2009). National University of Singapore, Institute of Systems Science. Delivering Organizational Coherence: The Future of Enterprise Architecture Keynote Session. Enterprise Architecture 2009 International EA Conference of the Danish IT Society. Copenhagen, Denmark. September 17 – 18, 2009

    Recommended Readings















    Note on the "Market Coherent Enterprise"
    I have called this concept many things. And we can call the concept whatever we want really. I have previously called it The Ever-Alert Enterprise, which is borrowed from MarketCulture Strategies. And I could be calling it the "Real-Time" Enterprise, as suggested by John Goetze, my thesis advisor and co-author of Coherency Management. The fundamental concept is that we are looking at the enterprise from two dimensions:
    1. An enterprise that is [externally coherent]. Coherent with its market. Ever-sensing and evolving in tact with its market. It's market-driven. Market-aligned. Market responsive. Boundaryless.
    2. An enterprise that is [internally coherent]. Coherent in operations. Optimizing the utility value of the external coherency. It's coordinated. Strategically aligned. Transparent. Efficient. Predictable. Agile.
    What do we call this ideal? Do you have any suggestions? Any thoughts?

    Sunday, May 9, 2010

    What is a Market Orientation?

    I'm doing some synthesis of the literature that exist around the Market Orientation construct, refreshing our understanding of what it really is.

    A great seminal piece is the one written by Jaworski & Kohli (1990) "Market Orientation: The Construct, Research Propositions, and Managerial Implications".

    Informed primarily by the Jaworski & Kohli (1990) piece, I've put together a model providing an overview of the various components of a Market Orientation. There are several more layers to it, especially when we begin talking about antecedents and consequences, but for now let's just focus on what elements has been identified as the foundational cornerstones of an MO.



    The model created categorizes our MO components in two domains
    1. A Coordination domain
    2. A Market Intelligence domain
    These two domains will guide us when sorting the various MO building blocks. Looking at the domains in a different way, you can say that the Coordination domain is internally focused, and the Market Intelligence domain is externally focused - one is facing how Market Intelligence is used within the organization, the other is facing the generation of Market Intelligence, intelligence which by nature is external to the organization. A major influence on this division is Jaworski & Kohli's (1990) definition of MO as "... the organization wide generation, dissemination, and responsiveness to market intelligence".

    The definition proposes three "pillars" of an MO 1) the generation of Market Intelligence 2) the dissemination of Market Intelligence, and 3) responsiveness to Market Intelligence. The trained eye will see that I have not separated the "responsiveness" component into its own domain (yet). This is an intentional choice at this point in the early synthesis, because "responsiveness" can be considered part of how the Market Intelligence is utilized internally in the organization. In other words I decide to categorize responsiveness as part of the internally facing domain. Another element of the definition that needs clarification is the term "market intelligence". I want to emphasize that the model presented also makes a decision on this point. Specifically, a decision is made on what market intelligence is, and what it is not just, and furthermore what the relationship is at a meta level between the elements that make up "market intelligence".

    I see market intelligence, and this is in agreement with Jaworski & Kohli (1990), as encompassing both the customer intelligence and the exogenous elements such as the traditional PEST forces (political, economical, social, technological) - and the attention to the PEST elements is solely out of a strategic concern for how to satisfy the customer in the midst of such forces. The customer remains core. The customer remains the key focus, unyielding. Thus, the PEST elements cannot be put at the same level as the customer focus, they are simply part of the picture because they have an influence on how we can satisfy our customer's needs and what our customers needs are, and for that reason only are we interested in it and need intelligence about it.

    Here some brief comments to assist interpretation of the model.
    Two general principles are:
    • The closer to the center the more weight (don't get out your ruler, it's really mostly to stress the customer focus)
    • The circles inherit from the core, i.e. since the customer is core, the customer is part of the equation everywhere.
     The Market Intelligence Domain
    As said above, the most important aspect of the Market Intelligence domain is still the customer. The Customer is our focal point of the entire MO philosophy (I think we tend to forget this, which is why I stress it so much)... Notice that the customer focus is not simply about what current needs they have, but also what future needs they may have. We want to know if our customers' needs or habits are changing so that we can change with them. Or we may even be influential in shaping our customers' needs. We may launch an iPad or something of that nature.

    The five areas that float around the Market Intelligence Domain (competition, politics, economics, social and technology) are all included because they have an impact on our core focus, the customer. And they are thought of in that regard, not as stand-alone items requiring their own separate attention. Again, remember that all the layers inherit from the core.

    The Coordination Domain
    I should have called this the "Coordination of Market Intelligence" domain, but it got too long... Again, the circles all inherit from the core. Thus, it is the coordination of market intelligence, the responsiveness to market intelligence, and the strategic direction and alignment we can form around market intelligence that is part of MO, as depicted here. It is not general coordination of everything we do in the business. It is coordination of the things we should be doing informed by a clear focus on how to best satisfy our customers needs.

    If you are serving internal customers, that's OK - the MO construct is still valid and can be used out of that objective - but still remember that you are just feeding into a larger value pipeline that ultimately should lead to superior external customer value. Apply an internal mindset if it helps you sort your thoughts around how to best contribute value, but just realize that the value generation does not stop there. Again, the external customer is still core.

    Wrapping up for now
    There are tons of other important dimensions of the MO construct to be discussed. For now we have just discussed the fundamental building blocks of an MO. As indicated above, especially a discussion of the antecedents and consequences of an MO is in place. What influences the presence and the thriving of an MO in an organization? Why is having an MO important? Can you "implement" and MO? Many more questions unfolds under these questions. It's easier to address them all separately. One thing at a time.

    Call for Comments
    If you read this and have build your own thoughts around it, please share them with me.. If you think I have forgotten something, please tell me..