Introducing: Ecosystem Quality Attributes

There are benefits to taking an idea from one domain and applying it to another.  We all know of the famous case of “software patterns” that emerged from the concept of architectural patterns developed by Christopher Alexander for the world of building design.  Similarly, we have recently seen the emergence of checklists in medicine which is an idea borrowed from other complex domains (like airplane piloting).

I’m going to follow in that long path of “cross-domain pollination” to take an idea from software architecture and apply it to business architecture.  Not a big stretch for an Enterprise Architect, I know, but I’ve not seen this idea discussed elsewhere.  (Just because an idea is obvious, that doesn’t mean people will think of it: witness the length of time it took to add wheels to luggage!)  That said, I leave open the possibility that prior art exists, and that I’m simply not aware of it.  If that is the case, please don’t hesitate to point it out.

The concept I’m going to borrow from software architecture is that of System Quality Attributes.  They are the various “-ities” that a software system exhibits. These include Scalability, Reliability, Maintainability, and many others.  System Quality Attributes can be used to measure the ability of the system to meet business needs.  There are lots of ways to use SQAs but I am going to focus on one specifically valuable practice.  In my opinion, the best thing you can do with software quality attributes, during system planning, is to prioritize them.

Prioritizing the relative importance of a system’s quality attributes, early in system planning, can have a dramatic impact on the design of the system.  The design is simpler, and more intentional, because the goals of the system are more clear.  A prioritized list of System Quality Attributes provides “guard rails” for the design of a system.  Creating this priority, and then driving a design to meet it, is the domain of the solution architect.

Now for the new concept: Ecosystem quality attributes. 

Ecosystem quality attributes are the specific measurable attributes of a coherent ecosystem of business processes, information systems, and human actors constructed to deliver the required capabilities demanded by an organization’s business model.

At the highest level, an Ecosystem quality attributes may be applied across an entire operating model.  (For the sake of this approach, an operating model is the widest example of a business ecosystem).  EQAs may also be applied at the level of end-to-end business processes within an operating model. 

Hypothesis: The relative priority of Ecosystem Quality Attributes can have the same dramatic effect on ecosystem design as we’ve observed at the system level through the prioritization of System Quality Attributes.

Managing that relative priority of these attributes for each business model, and influencing the emergence of the operating model to deliver it, and then governing the systems within that ecosystem to insure that it comes into being, is the domain of the Enterprise Architect.

Attribute Definitions

In this section, I will outline a relatively useful set of Ecosystem Quality Attributes (EQAs) that an Enterprise Architect can use to measure their business ecosystem.

Note that Ecosystem Quality Attributes measure a business ecosystem, and therefore must include information that is not available unless you work outside the “boundaries” of IT.  In other words, using a system of EQAs to measure a business ecosystem is a business method, not an IT method.

Ecosystem Quality Attribute	Description
Operating Model Alignment	A measure of how well the ecosystem of processes, information, systems, and roles align to meet the business model and operating model requirements of the enterprise.  The business model places specific requirements on the ecosystem, requirements which may change as external influences, opportunities, customers, and markets change.  Systems that do a poor job of keeping up the the changing requirements of the market incur a “tax” on customer loyalty, top line revenue, customer service costs, and operational efficiency that is difficult to address without systemic change.
Federation Consistency	A measure of how well the ecosystem supports, defends, and enforces the vertical division of duties, responsibilities, and accountabilities demanded by a federated decision structure.  Federated decision structures are very important in each of the four CISR operating models, but they apply in different ways with different amounts of federated control.  The ability of the system to keep “true” to the principles of federation intended for the ecosystem, with a minimum of unnecessary stress, is reflected by this measure.
Collaborative Maturity	A measure of how well the people and processes within an ecosystem support collaboration, ranging from information sharing at the low end, continuous measurement as a normal practice, and continuous improvement at the high end.  Core contributors to collaboration effectiveness, like shared commitment, consistency, culture, and expected level of rigor, all play into the level of collaborative maturity of a business ecosystem.
Dependency Risk	A measure of the relative strength of the ecosystem as indicated by the number of dependencies taken on immature capabilities, information sources, systems, and shared processes.  A business process that takes a dependency on a weak supporting system accepts an increased level of risk as a result of that dependency.  Business leaders may decide to reduce the number of dependencies or increase the maturity of the supporting systems, based on their preferences for business efficiency and effectiveness.
Information Consistency	A measure of the consistency of the core information elements across the breadth of an operating model.  A low level of consistency drives a “hidden tax” on efficient operations and business intelligence that is difficult to quantify.  Higher consistency reduces this tax, improves information velocity, and can have dramatic impacts on the ongoing costs of maintaining a business intelligence infrastructure.
Interaction Complexity	A weighted measure of the number of interaction points between independently managed business elements (business units, information systems, master information stores) needed to perform core business processes within the ecosystem.  Weight is applied to interaction points indicating the level of standardization and isolation in the interactions themselves, so that factors that lead to increased cost of ownership drive up the measure.
Readiness Complexity	A measure of how difficult it is for stakeholders to the ecosystem to learn to behave within the expectations of the business processes and culture of the ecosystem.  This includes readiness with respect to key scenarios, customer requirements, conceptual ontologies, key decisions, governance mechanisms, implementation details, systemic problems, planned roadmaps, change project status, and outstanding list of incidents.

 

Open question: is this the “right” list?  Am I missing elements?  Are there attributes that are not important from an ecosystem standpoint, and if so, why?  Answering these questions will require research, and is beyond the scope of this article.  I am more than willing to consider this list to be an “initial draft” for the use and refinement of the EA community. 

Prioritization and Tradeoff Method

It is a well-accepted premise, in software architecture, that there is no such thing as a perfect system.  A system has to be optimized for its use, and in doing so, the designer of the system has to apply tradeoffs.  We accept this idea without thinking in our daily lives: that a car can be designed for speed, or towing capacity, or gas mileage, but you cannot optimize for all three.  You have to set up your priorities, and optimize the system on the basis of those priorities.  A Sport-Utility Vehicle may put a priority on towing capacity first, acceleration second, and gas mileage last.  A small commuter’s car may reverse those priorities.  Both are acceptable.

I posit that the same is true for business ecosystems.  There is no perfect operating model or end-to-end business process.  Each is designed to suit the specifics of the business that demands it, and the business culture that drives it.  Each business ecosystem has to be optimized for specific quality attributes, and priorities must be taken.

So the challenge of this level of business architecture is to illustrate the importance of these attributes and host a discussion, among your business stakeholders, about the relative priority of each.  The deliverable is a simple document illustrating that priority and commenting on the intentional tradeoffs that result. 

What are some of the questions that your business leaders will consider:

• How important is it that your business be constantly improving?  Is it more or less important than the need for information consistency? 
• Does your business culture foster interdependency or would you prefer federation? 
• Do you need to be able create a copy of yourself, where readiness matters, or can the business take on large scale interaction complexity in order to create market differentiation for the products and services?

 

The process works like this:

1. Present the ecosystem quality attributes (in concrete terms, with example tradeoffs) to a set of senior execs and host a discussion.
2. Create a simple document resulting from the discussion that outlines the “decision criteria” that managers should use when improving their processes and systems.
3. Run that document past the execs to make sure that they agree with your distillation of their ramblings, and with your plan to communicate the results.
4. Communicate the resulting priorities to mid-level managers, key subject matter experts, and the folks involved in making changes to the business (especially Quality, BPM, and IT professionals who are frequently involved in tradeoff decisions).

 

Value proposition

So why should we host this discussion?  What is the value of taking the time of senior business leaders to make them consider the relative importance of complexity, consistency, readiness, (etc) in their business? 

The value is in building a company that knows what it wants, knows how it will go get what it wants, and wastes as little time, as possible, debating the relative merits of obscure decision points, or fighting political battles based on competing business goals.  The value is in clarity.  If you WANT a company that is able to replicate itself at the drop of a hat, say so.  If, on the other hand, you want a company that uses a complex set of interactions in order to create a wide array of different services in the marketplace, saying so will reduce internal “churn” that occurs when smart people are left to their own guidance about what is the “right thing to do.”

Example (Help Wanted… Looking for victims volunteers)

When I outlined this blog post, I thought “I will describe this concept with an example, here.”  However, as I got to this section, I decided that it would be more effective to ASK for your input than to tell you what an example should look like.  So… I’m looking for volunteers.  If you are an EA or a Business Architect, and you’d like to submit yourself to a two-hour telephone call where I ask you probing questions about your business model, business culture, and business behavior, then I’d like to hear from you.  Taking your input, I’d like to produce a couple of sample “ecosystem quality attribute prioritization documents,” and using that experience, refine the method. 

So if you are game for a phone call, drop me a line.  I will be in the New York/New Jersey area in about two weeks, and in the Chicago area for a few more days, in mid September.  If you’d prefer to meet in person and it works out to be convenient, perhaps we can do this face to face.  Respond by clicking the link labeled Email Blog Author in the upper right hand corner of the page.

Conclusion

I don’t find it “startling" or “novel” to say that Enterprise Architecture should directly impact the structure, function, or responsibilities of various business units.  My readers know that this is not a new proposition for me.  To the contrary: I believe that an EA that does NOT have the intent of impacting the business itself (in terms of business unit alignment, processes, roles, scope, funding, or vision) is not performing the role of an Enterprise Architect. 

The EQA concept and method is very much in the domain of Enterprise Architecture, not IT.  This method is concerned with the measurement of the structure and function of the business itself.  Where that structure and function is influenced by software systems, then IT folks would provide input.  Information Technology is not, however, a predominant concern. 

That said, the business method I described borrows shamelessly from the concept of System Quality Attributes and the ATAM architectural method.  I believe that the concept is sound and that a rigorous approach to business architecture, along the lines outlined here, has the potential for providing clear, simple, and elegant guidance to the army of business people (including IT folks) that are charged with taking the often-nebulous intent of business leaders and translating it into an effective, intentional, enterprise.

As always, dear reader, I’d love to hear your feedback.

Comments

• Anonymous
  August 31, 2010
  Nice one, Nick - very nice. :-) On 'prior art', my feeling is that you're right: I've seen several themes that dovetail into this, but probably none that match exactly. For example, the TOGAF ADM's Architectural Principles describe the same overall area, but these define the activities and metrics that are needed to action those principles. In principle Balanced Scorecard and its subsidiary metrics should describe a similar space, but it's both too fine-grained (metrics) and coarse-grained (Scorecard) compared to what you've described above. My own work on service-oriented enterprise-architectures - see 'The Service-Oriented Enterprise', tetradianbooks.com/.../services - tackles this area with what I've loosely termed 'pervasive-services', dealing with quality-management in the broadest sense: but they would need support from your Enterprise Quality Attributes metrics, which aren't described in that book. And although many of us have pointed out that the tern 'non-functional requirements' is a huge misnomer and should be referred to as 'qualitative requirements', I don't think anyone's pinned it down before in the way that you've described here. So yes, to me this does look new, and important. The key driver here - as also comes up in that theme of 'non-functional' versus 'qualitative' - is that the qualitative requirements often have the most impact on the architecture. There may be little difference in function between a system that delivers a 99% uptime (i.e. four days downtime per year) versus one that must be able to guarantee 99.999% uptime, but there are huge architectural challenges to get to the latter level of reliability; likewise there are significant architectural differences between a system that's allowed to have all of its downtime in one block, versus one that must spread it very thinly over time. If your EQAs can assist execs to understand the architectural trade-offs (and costs) of those aspects of quality, that would certainly help us all!

• Anonymous
  September 01, 2010
  Nick, Great article with interesting insights. For me a quality attribute for reading a blog is that all text is readable. But I can't read all of the text in the table where you explain the EQA's. Can you fix that? Thanks.

• Anonymous
  September 01, 2010
  My apologies, Renzo.  I made the change you requested in the formatting and republished the post.  I will remember to cross-check the formatting next time.