When is the last time we’ve seen truly new thinking in the area of Architecture for business and IT systems?  Zachman Framework, 1984?  TOGAF, 1990’s?  OMG Model Driven Architecture, 2001?  Has there been any breakthrough thinking other than to continue to provide more clarification and more decomposition about how to document enterprise and IT architecture?  There has, but change is painful even for a profession that prides itself in facilitating change.

I came across an interview article by Dana Gardner, president and principal analyst at Interarbor Solutions, with Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research. 

I thoroughly enjoyed the book Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, which she co-authored.  It’s a recommended read for Enterprise Architects.

In the interview Jeanne Ross shares how Enterprise Architecture and Enterprise Architects can help lead the way to successful business transformation.

Some key points from the interview:

“high performers in our sample of 102 companies, in fact, had greater architecture maturity.”

“there’s a cultural shift that takes place in an organization, when it commits to doing business in a new way, and that cultural shift starts with abandoning a culture of heroes and accepting a culture of discipline.”

“One thing you can’t get by spending more money is discipline, and architecture is very tightly related to discipline.”

“companies who were best at adopting architecture and implementing it effectively had cost pressures.”  Cost pressures force a company to make tough decisions.

“companies are struggling more than we realized with using their platforms well.”

A message for Architects is you need to understand how effectively are people in your company adopt the capabilities and leverage them effectively?  “the value add of the architecture is diminished by the fact that people don’t get it.”  “It requires persistent coaching.”

“The best architects are listening very hard to who is asking for what kind of capability. When they see real demand and real leadership around certain enterprise capabilities, they focus their attention on addressing those, in the context of what they realize will be a bigger picture over time.”

Companies need to ensure their enterprise architecture does not constrain them but instead enables them.  Effective Enterprise Architects can usually see the big picture even when the overall vision is not yet clear.

“What ends up happening instead is architects recognize key business leaders who understand the need for, reused standardization, process discipline, whatever it is.”

She’ll be sharing more insights at The Open Group conference in San Diego later this month.

I’ve been watching an interesting discussion this week taking place from a number of different organization related to cloud computing – or more accurately the perspective of cloud computing. With some of the early stumbles to developing a cloud marketplace behind us, it may be time to sit back for a moment and think about what is needed and where the cloud movement is headed. It also made me look at some of my old posts to see if they were still relevant.

A consensus of perspectives from the discussion:

• Cloud is a journey – It is not an implementation that gets done. It is definitely not just a single application living in isolation. It might start out that way but that is more of a Proof of Concept than an enterprise approach. There are many misconceptions that will be overcome as we go down this road so being flexible is important.
• Cloud is about People, Process, and Finance more than just the Technology. Sure it requires technology to compute the results but it is the people who collect the value. It is the processes that allow it to operate reliably (especially if you’re talking a private cloud) or the support of the business processes that actually generating business value reliably.
  It is finance as well – the value generation for $$ spent is one of the driving factors.
  Organizations need to have a holistic cloud view of the impact with the business. It is not just an IT issue. Having said that though, automation is at the center of the cloud. Understanding the capabilities and looking for business opportunities to take even greater advantage of integration and automation should also be part of a cloud strategy.
• Cloud is not magic and in many cases we have been doing “cloud” like implementations for years. I came from EDS and we sold multi-tenant solutions on the mainframe since the 1960s, so there is a great deal that can be learned from experience. Having said that though, the hardware capability and the software controls have advanced significantly, so although many of the tasks to be performed may be the same, the techniques available are radically different. 
  Another way that cloud is not magic is that the organization’s applications were probably not written to take full advantage of a cloud environment. They may run on virtualized infrastructure, but the software development techniques of the past will not be up-to-the-task of supporting cloud environments fully.

• Cloud is justifiable by the business outcomes achieved. It is a journey not a destination. Organizations need to implement for a reason and measure against those objectives. It’s OK to have a false start, make mistakes – as long as we hit the business objectives.
• Cloud is a delegation of responsibly. Organizations may have a cloud contract, but are still responsible. Not everyone feels comfortable with delegating responsibility at the same level – that’s OK. Just keep in mind that the cloud value is about leveraging for the good of the many. If you need something too unique, it will be a custom service and that usually costs more. Depending on the volume and the need, vendor self-selection is part of the cloud decision making process. Be careful trying to force a vendor in a direction if it is not where they are going anyway.

Those were some quick notes I wrote down. What did I leave out? Do your perception’s differ?

Existing business models provide useful abstractions of the design and operation of an enterprise.  However, optimization of the enterprise requires multiple viewpoints, and these viewpoints must reflect a consistent underlying design.  Integrated models are essential to management of continuous change and optimization at an enterprise level.

When each viewpoint represents the current state of the enterprise, then the enterprise itself determines the consistency of the viewpoints.  However, when we consider a future state of the enterprise, there is a need for a unified representation of the future state to ensure that the viewpoints are consistent.  This is essential for a full understanding of the implications of changes since changes from one viewpoint will likely have effects in other viewpoints. 

In the Object Management Group (OMG) we have developed and continue to develop specifications for business modeling viewpoints.  These define models that are useful as stand-alone abstractions of the business, and support the development of viable software products.  However, there is increasing concern that these models should be integrated-that they should be viewpoints on a more comprehensive model of the enterprise architecture.

The OMG recently chartered an Architecture Ecosystem special interest group to consider approaches to integration of models.  Preferably the solution would support integration of not only models defined by OMG, but other models as well.  So the solution should not require changes to existing modeling specifications, but should provide a means to integrate heterogeneous modeling technologies.

Integration of these models involves aligning the representation of the same concepts that occur in different models.  Sometimes the same concept will have different names, and sometimes the same name will be used for different concepts.  Sometimes the same business entity appears differently in different viewpoints.  Consequently, the reconciliation of model elements becomes an issue of semantics-their meanings.  If elements from two viewpoints represent the same thing, then they should be represented once in the integrated, enterprise architecture model.

There has been a lot of discussion about semantics.  Should OMG specifications be represented in RDF (Resource Description Framework)?  Should the integrated enterprise model be a semantic model?  How do the OMG SBVR (Semantics of Business Vocabulary and Rules) and the ODM (Ontology Definition Metamodel) specifications fit into this picture.  How big would a semantic model be?  Does it only represent concepts that appear in viewpoints, or does it require the representation of related concepts in order to properly qualify the concepts of interest. 

I think we need to back up a bit and consider the problem we are trying to solve.  Ultimately we want a model of the enterprise that supports multiple viewpoints, stored in a database to be accessed and updated from multiple viewpoints.  So let's think about this as a database problem.

There's nothing new about views of a database.  A view defines a subset of the database that supports a certain purpose.  So each modeling viewpoint needs to have a view of the database to store or display that model. 

But first we will need a data model for the enterprise model database.  The database must store a union of the sets of data elements that make up the viewpoint models.  The challenge is to reconcile the elements that represent the same concepts in different viewpoints.  For that we need semantics.  We can consider if that means we need to create a semantic model or just a mapping of data elements performed by humans.

The other problem we must solve is the integration of updates.  If two or more modelers are working on different viewpoints that include some of the same business elements, what happens when they put their models back into the database?  Again this is not a new problem.  That's what locking is for.  When a viewpoint is retrieved, the elements are locked so that they can't be changed until the changed viewpoint is stored.  However, simple locking may prevent other modelers from doing their work, and changes to elements in one viewpoint may have implications to related elements in other viewpoints, so an update could make the enterprise model inconsistent. 

Consequently, there must be a discipline and supporting technology for updates that not only prevents conflicting updates, but provides a mechanism for reconciliation of changes that goes beyond the scope of changes made by a viewpoint.  This is similar to the problem of managing the development of engineering designs for complex products.

So I see these as two distinct problems: (1) defining the unified data model and mapping the viewpoints to it, and (2) reconciliation of updates.  I don't have the solutions, but I think this is a useful perspective for development of solutions.