/Tag: Integration

When does EA start to care about sociocultural influences?

By |2014-08-13T11:24:38+00:00August 13th, 2014|Enterprise Architecture|

Organizations do not work, in real life, like they work on paper.  On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information.  On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.

In real life, there are human beings and the tools that they use.  Sometimes the tools move information from one person to another.  Sometimes, they just aid in communication.  People meet and get to know other people, and they learn to trust some, and distrust others.  Some folks have different measures and motivations and just “pass by” one another.  Some subset of these people will have shared cultural values and expectations.  There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization.  Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently. 

Reality is a lot messier than pretty rectangles. 

Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change.  We are unique in that most other “change artists” are not focused on engineering and some even ignore science.  (see Daniel Pink’s TED Talk on the Surprising Science of Motivation).  Few even know how to spell aesthetics.  Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science.  Engineering is a mindset as much as a class of methods.  It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things.  Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.

As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise.  We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter. 

That is just lazy.

It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures.  We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do. 

The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at.  Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.

We should consider sociocultural information if:

  1. Sociocultural influencers can impact the speed of change in an organization.
  2. Sociocultural connections can impact the decision making and governance processes
  3. Sociocultural strengths would allow rapid improvement in business capabilities needed for a shift in strategy
  4. Sociocultural blind spots would prevent an organization from recognizing an existential threat


Think about it.  Do you believe that any of those statements are false?  I can find ample examples for each one.  So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?

It’s only hard because we haven’t tried.

(This post inspired by the many similar pleas shared by J.D. Beckingham in social media).

Placing Architecture Properly into Scrum Processes

By |2016-09-28T22:44:52+00:00June 11th, 2013|Enterprise Architecture|

As I’m about to complete my share of a longer engagement on using Lean principles to improve the processes at an online services firm, it occurred to me that the efforts we undertook to properly embed Architecture practices into their Scrum process were novel.  I haven’t seen much written about how to do this in practice, and I imagine others may benefit from understanding the key connection points as well.  Hence this post.

First off, let me be clear: Agile software development practices are not at all averse to software architecture.  But let’s be clear about what I mean by software architecture.  In an agile team, most decisions are left to the team itself.  The team has a fairly short period of time to add a very narrow feature (described as a user story) to a working base of code and demonstrate that the story works.  The notion of taking a couple of months and detailing out a document full of diagrams that explains the architecture of the system: pretty silly.  (more…)

Everything you’ve read about IT Project Failure is wrong

By |2012-12-09T17:52:16+00:00December 9th, 2012|Enterprise Architecture|

I did a scan around the web to figure out what many of the leading thinkers were saying about IT project failure and the root causes.  Numbers varied between 20% and 80% of projects failing to deliver on their business case.  The root cause analysis that follows from these failure numbers spends a lot of time looking at the IT project, but most forget to look at the causes of failure that are outside the project’s control.

In the diagram below, the central blue box represents causes of IT project failure that are inside the control of the IT team.  As you can see, there are many more causes of IT project failure that are OUTSIDE that blue box than inside it.  Yet, countless articles have been written on the factors INSIDE the box.  I think it is time we take a slightly wider lens to the problem!


The factors outside the project are as important, or more important, than the ones inside the box.  I have worked on many projects over the years, and if I look back at the ones that ended up cancelled or scrapped, the reasons were not ones in the blue box.  They were usually ones from the top box: where the project should not have begun in the way that it did.  Let’s look at these six factors:

  1. Lack of accountability for success – Sometimes, in an organization, an interesting situation will arise.  I call this the “can’t lose” scenario.  In this scenario, the CIO will suggest that the business can benefit by doing some particular initiative, and his or her people will set out to find a business sponsor for the initiative.  In this case, the sponsor will reap the benefits of the initiative, not the CIO.  (Let’s say that the CIO has suggested a Business Intelligence initiative, and signs up the Chief Marketing Officer to sponsor it).  If the project succeeds, the sponsor wins.  If the project fails, the CIO (not the sponsor) loses credibility.  After all, it wasn’t the sponsor’s idea.  The CIO dreamed it up, after all.  In fact, the sponsor may not do any real “sponsoring.”  He may sit in an occasional status meeting and check his e-mail while the program manager he assigned from his team answers questions… and keeps him protected from any blowback.  The sponsor in this case is not accountable for success.  No one is.  The odds of this project succeeding are small.  (Note: a good IT Governance system prevents this condition). 
  2. Failure to get buy-in from above – Often, a senior executive will ask his operational leaders to suggest IT projects for the planning cycle.  The executive (let’s say Tina Smith, Vice President of Sales) assumes that the leaders (William, Ashok, and Lee: all three are General Managers) will ask for projects that align to their individual strategic needs.  One of those General Managers, William, decides to create an IT project to implement a SOA service bus.  He wants the bus because he is investing in replacing an application and his IT team tells him that a bus is a good idea.  After all, if everyone in the Sales group uses it, everyone will benefit.  But William doesn’t get Tina Smith’s buy in.  He implements his SOA service bus, but when subsequent IT funding requests come up to move other sales applications over to the bus, his peers Ashok and Lee are not interested.  Their priorities don’t include moving to the bus.  William bought a white elephant.  Because he didn’t get Tina’s buy in, none of his peers will reap the benefits.  Is the SOA bus a failure?  Well… it’s not a success.
  3. Misaligned prioritization – Lee James, General Manager of Sales for the Western region of Contoso owns a sales strategy for the enterprise.  The strategy is to make the sales force more productive by moving the company over to a new CRM system.  The CRM system has out-of-the-box support for a long list of reports, but his team tells him that he shouldn’t use those.  Instead, he should put in a Business Intelligence system in the cloud.  Lee wants to trust his team to pick the right solution.  They tell him that the cost of this system is $4 Million over two years.  The company is moving to a new strategy that de-emphasizes the direct sales force.  Instead, the company will be relying on social networking and direct eRetail to make sales.  To make the new strategy work, there are eight projects totally $8 Million that need funding.  There is a competition for dollars in the IT budget.  Lee goes to bat for his $4 Million commitment.  It’s important because “we are already here, so we have to complete the job.”  This is an example of misaligned priority.  The new BI project can be safely cancelled or scaled WAY back to support a strategy elsewhere, but that other strategy doesn’t belong to Lee.  The one that he owns needs money and he’s going to keep fighting to fund it because his boss, Tina Smith, isn’t aware of the tradeoff.  Lee fights, and Contoso loses.  Which project will fail?  Both of them.
  4. Slow decision making – This one is related to the other problems in that it is often, but not always, caused by a poor governance system or poor prioritization of the effort.  In this scenario, the team implementing the project needs the sponsor to make a decision, often one that requires consultation with his or her peers or counterparts in another part of the company.  The sponsor may be unwilling, unable, or incapable of having a difficult conversation.  On the other hand, they may be indecisive.  Regardless, this situation can cause serious delays in a project.  For example, Ashwin’s application sends EDI-formatted messages to a health insurance provider.  The provider had indicated that new fields are allowed in the messages that are very valuable to Ashwin’s line of business.  However, he has to upgrade his EDI translation software to get the new fields.  The EDI translation software is also used by the Finance group to send banking transactions.  Ashwin knows that the finance group will get a benefit out of the upgrade and wants them to help cover the costs.  This upgrade will add $25,000 to the cost of his project and he’s on a tight budget.  The software team offers to write a small component that will insert the fields into the data stream, but its complicated and fragile. Ashwin cannot decide if he should ask the finance team for funding or if he should upgrade the software.  The project team cannot proceed without a decision. 
  5. Lack of authority to drive change – This one is quite common.  Ashok reports to Tina Smith, VP of Sales for IBuySpy.  He has told her that he wants to take the lead on one of her strategies
    : to consolidate all of the eCommerce systems in the company to a single outsourced vendor.  Tina things that this will reduce costs all around, and Ashok is happy to take on the challenge.  His business analyst does a survey and it turns out that the services and support team offers customers the right to buy replacement parts online.  In addition, the “outside services” team allows customers to buy a service contract on their own area of the website.  The main sales site, of course, uses a high-volume low-cost vendor that Ashok is comfortable with.  Ashok sets up meetings with the owners of the other applications, but they choose not to provide the needed transaction cost information or the cost estimates of changing their internal systems.  His data is light but he strongly suspects that there is a good business case for switching.  Unfortunately, he doesn’t have the data to prove it.  Without data, the Tina won’t take the case to the CEO to require the other teams to jump onboard.  The strategy fails.  Neither Ashok, nor his manager Tina, have the authority to require their peers to adopt a lower cost system.
  6. Lack of influence to rally peers – In many organizations, the prevailing attitude is that the boundary between “centralized” services and “federated” services is intentionally fuzzy.  In these companies, there is no policy that requires a function to be centralized vs. federated.  For example, if a company has ten divisions, three may have their own financial processes, while the other seven share a common finance unit.  The decision to use the central finance unit, or to own a federated unit, can be made and unmade depending on who the leaders of the business are.  (Note: leaders change, and with them, these decisions change as well).  This kind of policy is good for flexibility, but creates both inefficiencies and often, confusion.  This is simply a tradeoff in the design of organizations.  It is neither right nor wrong.  In this environment, any business can create a “centralized” function by convincing more than one business leader to come together to create a shared resource.   The flaw comes when a group wants to create a “centralized” (or simply “shared”) function, but they lack the influence needed to get multiple businesses to join the initiative.  Difficult questions of shared funding can be demotivating, and the political need to create “alliances” can be difficult for junior executives that, in many ways, are competing with one another for the next rung on the career ladder.


Each of these conditions has the potential to kill an IT project.  I would suggest that MANY IF NOT MOST of the failures of IT projects can be traced to one or more of these conditions, but these conditions rarely get counted in the statistics for “Causes of IT Project Failure.”  Why?  Because, in most cases, projects that suffer from these conditions are either never funded, or are reworked so that the political problem is simply avoided.  The project business case does not reflect the problem, so the criteria for failure (doesn’t meet the business case) is never met.  Efforts are made to avoid (but not address) the problem before the business case is written!

This is the world of the Enterprise Architect.  These are the kinds of “failure” that fill the eyes and ears of an Enterprise Architect.  If an EA focuses on only these six causes, he or she will deliver real, tangible, and unique value to their enterprise without ever overlapping the roles and responsibilities of an IT architect, business analyst, or technologist.

Service Oriented Architecture Conceptual Model

By |2010-04-16T23:49:12+00:00April 16th, 2010|Enterprise Architecture|

Almost two years ago, I described some of the key concepts of service oriented architecture, including the distinction between a canonical model and a canonical message schema.  Since that time, I worked on a wide array of models, including Microsoft IT’s Common Conceptual Model.  That model (CCM for short) is the metamodel for IT concepts in Enterprise Architecture.

I received a note recently about that old post, and how valuable it was to the reader.  It occurred to me that those concepts were part of our Common Conceptual Model, and that a “SOA-Specific View” of the metamodel may prove interesting.  It was. 

I’ve attached the SOA view of our Common Conceptual Model for this post.

SV - SOA Concepts

A quick set of notes on my conceptual models.  

  1. Two terms separated by a slash (Application / Installable Software) are distinct terms for the same concept. 
  2. The associations are all “arrows with verbs”.  Read the associations along the direction of the arrow.  (e.g. “Application Component implements a Shared Service”).  I intentionally avoided using UML notations like “Composition” and “Aggregation” because they are difficult for non-technical people to read.
  3. Many verbs on an arrow – The stakeholders couldn’t agree on which verb best described the relationship, so we used multiple distinct verbs. 
  4. In my prior post, I used the term “Canonical Schema.”  Our stakeholders preferred “Shared Message Data Contract.” 


The key relationships to notice in this model are the ones that may be the least expected ones: the connection between the obvious SOA concepts like “Contract” and “Canonical Entity” and the not-so-obvious SOA concepts, like Business Process and Business Event. 

When SOA is done well, it is part of a seamless ecosystem between the processes that people perform and the systems that support them.  Being able to see the parts of the system and how they connect is key to understanding how to build a truly effective service oriented architecture.

How the Program Management Office Views Enterprise Architecture…

By |2010-03-10T12:58:15+00:00March 10th, 2010|Enterprise Architecture|

There’s an interesting analysis available through the PMO Executive Board on “Project Interdependencies.”  In the problem statement, the author correctly observes:

As the volume and size of projects grow, the old problem of managing project and program interdependencies is becoming more acute: three quarters of PMOs consider “managing interdependencies” to be one of their most critical program management challenges.

First statement is cool.

Unfortunately, the next concept is somewhat troubling to me.  According to the author, the solution to this problem is one of process 

“… the ability to track and communicate project interdependencies boils down to two essential managerial disciplines: good risk management and clarity of communication with senior executives.”

In other words, we can track and communicate interdependencies better if improve our ability to manage risk and communicate interdependencies.  Is that argument convincing to you?  Seems pretty circular to me.

Digging a little deeper

Let’s take a look at the “project interdependency problem” for a minute.  If projects had no interdependencies, there would not be a problem.  However, if one project must complete before another one can deliver value, then there is an interdependency. 

This is a problem because we may not know which project is the “critical path” project, so we may not do a good job of accounting for delays or cost overruns in the “source” project that can ripple across many other projects.  In that aspect, understanding the interdependencies is a CRITICAL problem for the Program Management Office. 

But let’s dig a little deeper.  What causes projects to be interdependent upon one another?  According to the same analysis, the factors to consider are:

  1. data,
  2. artifacts or deliverables,
  3. technical functionality,
  4. infrastructure capabilities,
  5. milestones, and
  6. end-user commonality.

Think through the list above.  How many are NOT architectural?  You could say that end-user commonality is not architectural, if you were to exclude business architecture from the discussion, but once you examine the kinds of models developed in an Enterprise Architecture context, 100% of the types of interdependencies chartered in these different projects are visible in, or predicted by, the architecture of the systems.

Improving the advice

I am not saying that a PMO shouldn’t be concerned with Interdependency management.  It is not the job of Enterprise Architecture to track, communicate, and drive the flow of the project portfolio. 

What I am saying is that the advice needs to be extended.    The second sentence above, and the entire presentation to follow, needs to recognize the clear dependency that the PMO takes, or should take, on the Enterprise Architecture team to identify, review, minimize, and prioritize systemic and project interdependencies. 

In other words, the second sentence above would become:

“… the ability to track and communicate project interdependencies boils down to three essential managerial disciplines: timely development and delivery of Enterprise Architecture, good risk management and clarity of communication with senior executives.”

SOA Optimistic Data Synchronization considered harmful

By |2009-09-04T20:58:00+00:00September 4th, 2009|Enterprise Architecture|

Let’s say that you have two systems: Adipose and BellyFat.  They both need the same information.  Adipose handles customer transactions, so it needs information about customers.  BellyFat handles the long-term management of customer information, like what products they have purchased and what rights they own.  It also needs information about customers.

How do we keep the customer information, in these two systems, in sync?  SOA offers three answers: Call-and-Response, Optimistic Data Sync and Pessimistic Data Sync.

  • Call-and-Response says: One system holds the data.  The other does not.  The system that does not hold the data calls the one that does, on a real time basis, and gets the data back quickly and efficiently.
  • Optimistic Data Sync says: Both systems keep a copy of the data.  If an event happens in either system, drop it on the bus.  The other system will get the event, interpret it correctly, and update its internal store to reflect the change.
  • Pessimistic Data Sync says: One system masters the data, but the other system keeps a local copy.  If an event happens in either system, drop it on the bus.  The other system will get the event, interpret it as best it can, and update its internal store according to its own business rules.  On a periodic basis, the ENTIRE data structure will be copied from the master to overwrite the data in the local copies (data refresh).

Each of these three has its own strengths and weaknesses.  One of them, Optimistic data sync, is so bad, however, that I’d like to call it out for special ridicule. 

Type Advantages Disadvantages
Call and Response
  • Any data entity exists once
  • Less duplication of data, lower physical storage
  • One view of the “truth”
  • Diminishes need for ETL capabilities
  • Easy understanding for software developers that are familiar with relational database design
  • Consistent inter-system data models not requireed
  • Constrains architecture – provider and consumer must be “close”
  • Requires highly available data providers
  • Cumulative negative impacts on overall ecosystem reliability
  • Requires highly scalable messaging infrastructure
  • Fosters point-to-point messaging
  • Leads to rapid increases in complexity and management cost
Optimistic Data Sync
  • Allows multiple systems to “master” a data entity
  • Diminishes need for ETL capabilities
  • Encourages loose coupling between systems
  • Supports systems that are wide distances apart. 


  • Requires highly scalable messaging infrastructure
  • Requires highly reliable messaging infrastructure
  • Assumes that data updates are always consistently applied
  • Data gradually gets out of sync, with no recourse to get it right.
  • Consistent data models are a necessity
Pessimistic Data Sync
  • Does not require expensive messaging infrastructure
  • The amount of “correctness” between systems can be carefully managed
  • Encourages loose coupling between systems
  • Consistent inter-system data models not required
  • Requires system architects to agree that one system is a master
  • Data gradually gets out of sync, but administrator can use refresh mechanism to resync
  • Requires ETL capabilities


You will choose one over the other depending on your tolerance for the “disadvantages” and your preference is for the “advantages” of any method.  However, and this is the focus of this blog post, one of these three is really not workable in the long run: Optimistic Data Synchronization.

The reason for my enmity for this approach is simple: this approach uses an underlying assumption that is poorly considered.  That assumption is that it is fairly easy for two systems to stay in sync simply by keeping each other abreast of all of the events that have occurred in either one.

The problem with this assumption is that it is NOT easy for two systems to stay in sync.  If the two systems don’t share an IDENTICAL data model, then each system has to interpret the messages from the other.  The rules of that interpretation have to be coded in each system, and that code must stay perfectly in sync.  Plus, there can be no errors in interpretation, or variations in the way that a change propagates throughout the recipient’s system.  There can be no variations in the event model between the systems.  No bugs either.  Sure…. if we can get to the point where no humans are involved in writing computer applications, then this might make sense.

Not long ago, I used to think that Optimistic data sync was a good idea, and that SOA developers should assume that their data exists outside their systems.  Heck, I used to think that call and response was a good idea too.  Both are bad in practice, with Optimistic sync being by far the worst.  There are just too many common scenarios (like one system going down for a period of time, and coming back up after missing some messages) that drives down the overall integrity of data managed in this way.

While I’d go so far as to say that Pessimistic and Call-and-Response are reasonable patterns for a SOA architect to select, the optimistic data sync method should be considered an anti-pattern, and avoided as much as humanly possible. 

Civil Engineering Analogy to Enterprise Architecture: Flawed

By |2008-09-13T19:29:46+00:00September 13th, 2008|Enterprise Architecture|

It is typical to see comparisons of Civil Engineering to Enterprise Architecture.  A number of papers from Gartner have made the comparison, as have many articles and conference discussions.  I have made the comparison myself.

It is a somewhat apt analogy.  After all, both EA and Civil Engineering are responsible for setting standards (codes) that constrain the efforts of other architects.

But this is a limited and flawed analogy as well.  Here is why.

Civil engineers envision this:


(Futuristic cityscape from CG4TV)

Enterprise Architects envision these:


(Futuristic cityscape from 7 art screen savers)

Notice a difference?  In the first picture, the buildings are pretty, but they are silos.  They are developed independently and do not interact with one another.  The "shared infrastructure" between these buildings is buried underground… (sewers, electric, phone, etc).  That paradigm has not changed in 100 years!   The only interaction is at ground level, where the front doors are.  The only "suspended" part of the image is a transportation system, but there is no evidence, in the image, that the suspended transportation system interacts with the buildings.  It appears only to avoid running into them.

The second image shows not only transport systems between buildings, but suspended sections of buildings.  Livable, workable, usable space between the buildings.  The way in and out of each building occurs at multiple places, and those connections are more than just for transportation.  In fact, how would you define a building in this city?   This is more akin to the problems faced by Enterprise Architecture.

An even better image is one that I couldn’t find.  It would have been to show the city in LAYERS, with buildings that support a PLATFORM upon which other buildings are built, or upon which those same buildings are extended, with each layer serving unique functions.  Perhaps the lower layer would include freight transport, the middle layer would perhaps include commercial and office spaces, while the top layer (closest to the sun and fresh air) would include living spaces and solar/wind power generation.

The civil engineering standards needed to produce a layered city are radically different from those needed to build a traditional city.  You’d need to allow for, or even require, the creation of foundations to support structures that exceed the needs of the bottom layer.  (e.g. a 10 storey building with foundations sufficient for a 60 storey building).  There would have to be a mechanism to insure that costs are not shifted in an unfair manner, and that builders could replace a lower-layer building without affecting the structures above it.

The point is that civil engineering, in practice, has not made the leap to layered cities.  (apparently, futuristic art has not made that leap either!)  Enterprise Architecture has. 

This is no criticism of civil engineering!  To be fair, it is simpler to envision layers in the cyber world of an Enterprise Architect, where distance is an abstract notion, you don’t have to worry about the deterioration of different materials, and both water and gravity are absent. 

The analogy between EA standards to building codes is flawed because the systemic constraints that these two professions must create, and the envisioned results they are trying to produce, are radically different from one another.  Comparisons between the professions are interesting, and somewhat instructive, but insufficient to advance the art of either one.

Put perspective on both short and long term problems

By |2008-03-28T16:47:00+00:00March 28th, 2008|Enterprise Architecture|

I’m always a bit worried when someone has “the answer.”  Lot’s of red flags go up when someone tells me: this is the problem and this is how you solve it.  Perhaps I’m just that kind of person.

I had a recent exchange with Alex Maclinovsky over at Sun.  Very practical guy.  Love his stuff.  We were discussing the idea of whether a common information model was a valid thing to kill off JaBOWS.  He agreed that is would be a really good thing, but that it is impossible to create.  I think his point is that we should have a model to refactor services as time goes on, and thus create a consistent set of services in a bottom up manner.  (Alex: I hope I understood you correctly).

So, when Alex suggested that it is a good idea to use a common information model, but that it just ain’t gonna happen, I guess I reacted in my gut. 

That’s a very short term perspective.

The problem at hand, most days, is building services for your app to expose, that others can use.  That is the short term view, and it is VALUABLE.  That is where the rubber meets the road.  In that respect, I agree with Alex.  We need to have a way to create versions around services, and to migrate them towards a cleaner model as time goes on.  To that end, Microsoft Consulting Services has created an open source project to ease the transition of service versioning called the Managed Services Engine.  I recommend all readers working in SOA on the MS platform to check it out.

On the other hand, if we take a short term view, without considering the long term, we can still end up with JaBOWS.  And that is the battle I have staked out.  It is a longer term battle.

So when we define the problem, it is fine to recognize the value of “extensible services” but it is dangerous to ignore the need for a destination… a place where we want to extend them to.

The interesting thing, really, is that Microsoft has a number of internal initiatives around creating a common information model.  There are at least four that I know of.  All of them are fairly complete.  Of course, they are different.  So the problem is not that we cannot create a model that covers all aspects of the business.  The problem is that we can’t get it to be recognized as a common model that covers all aspects of the business.  The difficult word is ‘Common’. 

We are working on it.

That said, the areas where we agree are immensely valuable, and even the areas where we disagree offer value because, in any one area, there are two “right” answers which means that, if you want to get things done, it is easier to pick one of them rather than create a third.  So we get governance via politics.  Not efficient, but definitely effective.

So when we attack JaBOWS, let’s have short term solutions.  Let’s include service extensibility.  That’s great.

But let’s also include longer term solutions.  Let’s let the “impossible” remain as a goal, because you will find that by keeping that impossible goal in mind, we end up getting there. 

So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable.”  (Christopher Reeve)

Standardization works with a limited, and rational, scope

By |2008-02-05T04:54:00+00:00February 5th, 2008|Enterprise Architecture|

I’ve been on a roll lately, calling for the creating of a standardized approach to the partitioning of Line-of-Business apps

One reader commented that we are a long way from “plug and play” integration.

The real answer is more subtle than that. 

Not all business are alike.  Therefore, one standard for all software doesn’t make sense.  I’m not calling for one standard for all software.  I’m calling for one standard for some software.  Specifically, LOB supporting software.  Allow me to explain.

First off: I’m talking about Line of Business software.  So, if am excluding “storage in the cloud” or “hosted collaboration” services (like hosted e-mail).  Not because they are not important… but because I’m looking at a different problem.


Line of Business applications are used to perform specific functions for the business.  Particular steps in business processes are automated using LOB software.  These processes are focused on things like “finances” and “human resources” and “order entry.”  Useful things. 

But what are these “things?”  How do we describe the “things” that a business needs to define it’s operational world-view?  These “things” are business capabilities.

A business capability is a description of the stable business functions (the things that must be done) in a way that allows the processes to change independently (processes describe how you do those things).  So, you could say that when a customer calls your business with a request for information, the customer is going to invoke the “handle customer request” business capability.  Whether that means a call center, or an IVR system, or just “folks in stores picking up the phone” depends on the business.  The capability is stable.  Every business needs to “handle customer requests.”  How those requests are handled… that varies.

In Business Architecture, we talk a lot about business capabilities.  The operational capabilities form a key part of the entire business model (just one part, of course). 

For the sake of clarifying my call for standards, however, I’d like to break down the capabilities into three layers.  From the bottom: Supporting, Industry, and Differentiators.


Now, I’d like to avoid a “taxonomy debate” right off the bat by saying this: I’m not suggesting that this is the only way to group business capabilities.  There are lots of ways to navigate the list of business capabilities.  I’m breaking them down this way because it is useful

I have grouped the capabilities into these groups because these are the layers at which companies can collaborate.  When you talk about standards, and creating shared best practices, and constraining software vendors, and leveraging the buying power of the market, then collaboration matters.

At the bottom of the stack, you have supporting capabilities.  These are the things that every company needs, and every system contributes to, but is too-often overlooked.  This is where you keep your information about customers, products, transactions, and obligations.  This is the ‘base functionality’ on which the entire enterprise is built. 

Companies can collaborate in this area because capabilities here provide no competitive edge.  We mostly have the same needs here, quite often across a wide array of industries.  Business schools teach courses in how to “do” the things that align with these capabilities.

The Industry specific areas are the focus of so many industry-specific standards bodies, from TMForum to Acord to hundreds of others.  Even the HIPAA standard is a form of Industry-specific standard created to support an Industry-specific capability: the filing of medical claims.  Everyone likes to collaborate here, but only other folks in your own industry really care.

The capabilities at the top are the ones that differentiate your business from your competitors.  If your business is willing to collaborate in this space, then you are (a) rare, and (b) probably either location or geography specific or you are a protected monopoly!  The rest of the organizations I come across, including Microsoft, have a set of capabilities that they keep quiet about because there is some value in how we compete.

Of course, the customer doesn’t see these things.  For the most part, the customer sees the image that a business wants them to see: the things that make a business unique.  That is what the brand is all about.  In a certain sense, the most successful businesses wrap their “supporting” capabilities and industry-specific capabilities with a layer of uniqueness and differentiation.  This is a slightly different perspective, but one that is useful.


Now, we have divided up the S+S space to focus on Line of business services, and within that, we have divided up the capabilities of a business into different layers.

The area where I believe we should standardize is not all software, or even all line of business software, but only the software underlying the Supporting Business Capabilities.

In this space, and ONLY in this space, do I see the need to create the first row of standards.

Then, on top of this space, I can see the need to describe Industry-specific models, like NGOSS/TAM for the telecommunications industry. 

The reason for doing this goes back to my initial post about a Shared Global Integration Model. 

One thing that is useful to realize about this standardization: I’m including the data model using the same hierarchy of business capabilities.  In other words, we should collaborate on the ‘supporting’ business model and allow industry-specific groups collaborate on the information that surrounds the center.  This creates an information model with many layers, each managed by different people.


I am getting somewhere with all of this, by the way.  My next post will go further into why the standards bodies are not getting this right today.  After that, I’ll talk about the software that we should develop to support / enforce / encourage these standards.

Standards and Innovation

By |2008-01-28T20:59:00+00:00January 28th, 2008|Enterprise Architecture|

When I opened my call for a Shared Global Integration Model, I expected some folks to say “we don’t need that.”  What I didn’t expect was the argument that standards are somehow a bad idea.

It’s hard to consider an argument against standards with a straight face.  A basic tenet of the modern age has been to reduce variation to increase quality.  This is a cornerstone of W Edwards Deming’s work.  Without standards, the quality revolution that lifted Japan to an economic superpower would not have been possible.

Standards in technology are not new.  You can get access to information on ANSI Standards dating back to 1978 at the Charles Babbage Institute.  We use standards in nearly every aspect of computing, from the ASCII (1963) and Unicode (1991) character sets to the TCP/IP protocol (1973) to the USB bus (1996) on our systems.  We use MPEG standards to store to share audio and video on our DVD drives.  Even the electricity coming from the wall outlets is delivered according to a standard.

So the notion that simply creating a standard constrains creativity rings hollow to me.

Sir Tim Berners-Lee, the father of the World Wide Web, has been speaking about standards for a very long time.  I direct you to a keynote address he gave at the 3GSM Conference in February of 2007.  

He first spoke about open platforms being “built to enable, not to control.”  He continued:

“So what else does it take to make an open Internet platform?

What does it take?

It takes, mainly, common standards. The innovation of the WWW was possible because the standards for TCP/IP were already implemented in an interoperable way all over the planet, in advance of the innovation. TCP/IP wasn’t designed with networked hypertext in mind. But it wasn’t designed to prohibit it either — it was and is an open platform.

Web 2.0 community Web sites, eBay, and Flickr are possible because the Web standards, in turn, were widely implemented in an interoperable way, before those innovations. The same for the wikis, like Wikipedia, and blogs, and so on. The Web is a huge platform for innovation because of those standards. Any new genre of communication, any new social networking idea, immediately can gain the value of unexpected re-use by people across the world.

There is a very important difference in attitude between a foundation technology and — well — let’s call it a ceiling technology. A foundation technology is designed to enable innovation, to be the base which will support other even more powerful things to come. A ceiling technology is not. It is designed to provide a value, and for its provider to cash in and cash out. Proprietary music download systems are ceiling technologies to the extent that the technologists design to be also being the only store in town, rather than creating an open market. Though putting a lid on further innovation, they are still providing a service, and making sure they profit from it.

Ceiling technologies are the end of the road for innovation.

When you want to make a foundation technology, you need to look ahead. You need to put aside the short term return on investment questions and look at the long term.”

I am not going to pretend that I am of the same stature as Sir Tim Berners-Lee.  I stand in his shadow.

But with respect to his sentiment, I agree.  He is correct.  It is the creation of a foundational standard that empowers and builds innovation.  Business software lacks that foundational standard.

The obstacles that inhibit rapid innovation in business software, of the same scale and scope as the web itself… these obstacles are artificial.    One-off integration mechanisms and transaction-only integration standards are obstacles.  They are ceiling technologies, designed to prevent innovation and lock each customer into a single vendor.

That must end.  The Software + Services trend requires it.  It is time to end the necessity of “vendor-lock-in through unique integration” by standardizing not only “one potential interface” as the Open Applications Group has done with OAGIS, but to go the next step and create a uniform standard model that unifies the platform for business software. 

In this new standard, each system is constrained in its scope, but not in its features or abilities.  This creates the standard “plug” that allows a new system to be built and for it to plug in to an existing infrastructure. 

This simple notion, to define the system boundaries along with the integration messages, allowing independent software vendors to create a single solution that will, through SIMPLE and INEXPENSIVE configuration, integrate WIDELY with HUNDREDS of other business software products, whether as an installed system or an Internet-available service. 

Two SaaS providers can easily compete with Microsoft and Oracle and one another, and customers benefit from the inevitable competition on reliability, price, quality, and features. 

I am a mere customer in this pawn-game.  But as a customer, I call for the “big guys” to step up, sign up, and build for a future that will not only risk the precious “lock-in” model, but will, more importantly, secure the future for the companies that lead the way.