Archive for the ‘Enterpirse Architecture’ Category

Achieving an Architecture Ecosystem

January 15, 2010

Having been involved in modeling and architecture standards for a long long time, the problem of modeling “stovepipes” has become increasingly apparent.  Even within one organization, like the Object Management Group, the modeling standards “don’t connect”.  For example the new Business Process “BPMN-2” standard does not have a clean way to share processes, data and services with UML models.  Despite both being defined within the “Meta Object Facility” (MOF) there is no semantic interoperability.  Kenn Hussey commented on the BPMN issues in his blog post “On The Future of BPMN (Too)”.

The problem with this is that architects, developers and analysts are developing information that is closed, hard to find, hard to integrate and not providing the value it could.  At a time when we must do a much better job making effective organizations, collaborating, sharing data and resources – we need this critical information.  

A new group has formed (which I am helping to chair) called the “OMG Architecture Ecosystem Special Interest Group”.  It is the mission of this group to chart the course for solving these problems, for making all of our modeling languages viewpoints on an underlying federated knowledge base.  Modeling in this context includes all forms of structured knowledge representation, including: Business Models, Vocabularies, Ontologies, Object Models, System Models, SOA Models, Data Models, Schema, Process Models, Domain Specific Languages, DoDAF, etc.

 When this capability comes on-line it will be a game changer – no longer will “business modeling” and “systems modeling” and “ontologies” and “vocabularies” be separate islands, but part of the integrated knowledge base of an enterprise, government agency or community.  This will help enable collaboration, information sharing and enterprise transformation.  Being able to share and relate architectures can also help acheave the open government goals.

 One of the approaches we feel has a lot of promises is to utilize the “semantic web” and “linked open data” (LOD) as the foundation for the architectural ecosystem – this will enable multiple models and modeling languages to be connected in the LOF cloud, yet retain their individuality.

 More information on this initiative is available here: http://www.omgwiki.org/architecture-ecosystem

Of course this is not easy – there are technical and a host of political issues, but with the work we have already done on the EKB, we know it can be done.  I hope we will be able to put together a groundswell of participation to achieve the ecosystem.

OMG Issues RFP for Any OMG Model or Architecture (UML, BPMN, SoaML, Etc) to use RDF Linked Open Data

December 17, 2009

At the technical committee meeting last week in Long Beach California, the Object Management Group issued a request for proposals to provide better connectivity between models and modeling languages defined in OMG and RDF Linked Open Data.

The OMG  is the premier standards organization for modeling, middleware and architecture.  OMG standards include UML, BPMN, UPDM (UML Profile for DoDAF), SoaML, SysML, Ontology Definition Metamodel, Model Driven Architecture (MDA), Records Management, Corba and may others.  All of these modeling standards are based on the “Meta Object Facility” (MOF) which uses the XMI interchange format for model interoperability.

The RFP issued last week will result in a standard for representing all MOF based models and modeling languages using RDF and Linked Open Data.  This has multiple advantages:  All OMG-MOF based models (UML, BPMN, SOA, UPDM, Etc) will be able to be published as Linked Open Data and thus take advantage of the LOD tools and community.  This will allow architectural information to be linked, queried with and analyzed with other kinds of information on the web and will also allow architectures to be linked and queried with architectures in incompatible models.  Architectures as data will become first-class citizens in the global data cloud.

The RFP asks for a “Structural mapping” which means that the model vocabulary remains unchanged.  For example, a UML model retains the UML vocabulary.  The structural mapping can then convert any kind of model without information loss, but it does not translate between vocabularies as is done in the UML class diagram to OWL mapping defined in the Ontology Definition Metamodel.  Other semantic mappings and ontologies are expected in the future.

More information on the details can be found in the RFP document here: http://www.omg.org/cgi-bin/doc?ad/2009-12-09

 The objective of the RFP is summarized as follows:

Title: MOF to RDF Structural Mapping  in support of Linked Open Data

RDF and Linked Open Data (LOD) have become important technologies for exposing, managing, analyzing, linking and federating data and metadata.  This set of RDF based technologies, sometimes known as the “Semantic Web” or “Web 3.0”, are emerging as the lingua franca of data on the web. Major initiatives such as the President’s open government initiative are moving to the use of RDF & Linked Open Data as the foundation for publishing all government data and metadata in support of transparency.  OMG & MOF based models should be a part of the LOD and Web 3.0 data cloud.
The objective of this RFP is to define a structural mapping between OMG-MOF models and RDF to provide for better integration of MDA and LOD, to enable the ability to apply LOD capabilities to MOF compliant models and to make the information available in MOF compliant models available as LOD web resources.  Any MOF based model should be able to become a LOD resource.

The model/LOD connection is also very good news for the Open Government Initiative which calls for government to be more open, visible, collaborative and participatory.  Government architectures are the primary source of structured information about government processes, services, rules and data.  As such the data contained in these models, which will become visible as Linked Open Data, will further the open government initiative.

ModelDriven.org has done a preliminary open source implementation of this mapping as part of the Enterprise Knowledge Base (EKB) project.  Those interested in participating in the standards and/or open source efforts are welcome to contact us for more information on how to engage.  Cory Casanave, who championed the RFP, may be contacted at: (cory-c at modeldriven dot com).

Please feel free to send  this notice to other interested parties in the ontology and modeling communities.

Lean Architecture – Architectures for Doing More with Less

November 9, 2008

I have been giving some thought to the practice of architecture and what we need to do in these times where we need to do more with less while enabling positive change.  My thoughts on the subject have come around to what I would call “Lean Architecture” – Architectures for doing more with less.  Community input would be appriciated as we develop the idea further.

What is Lean Architecture?

In these times of needing to do more with less, of having more responsibilities with less budget, we need to work and apply our resources smarter – a lot smarter.  Lean architecture is intended to bring together best practices across business and technology to do more with less. Lean architecture complements other successful approaches such as the Zackman framework, agile methods, total quality management and lean sigma.

Lean architecture applies at multiple levels; from enterprise and business architecture, through systems architecture to technology implementation.  It can include service orientation, business processes, information and business rules – depending on the problems and opportunities to be addressed.

Architected solutions can out-perform a chaotic system, if applied correctly and at the right levels.  However, not everything should be architected, as some things just worked better if they are self-organizing.  Lean architecture is understanding when and when not to architect a solution, and in how much detail.  It is understanding how a plan, process or design can say enough to be effective and efficient without stifling creativity and diversity.

Lean architecture delivers value, if it doesn’t – it shouldn’t be done.  The art of lean architecture is maximizing the value derived from planning and design of our enterprises, or missions and our technologies.

Five Core Principles of Lean Architecture

We have summarized five core principles of lean architecture.  These have been derived from decades of architectural experience – including those that delivered value and those that didn’t.  These are principles for deriving value from architecture to solve problems, reduce costs, foster agility and take advantage of opportunities.

A lean architecture should;

  1. Enable doing more with less using positive chnage
  2. Target a specific set of problems or opportunities important to stakeholders
  3. Express an actionable & verifiable plan or specification without stifling creativity and diversity
  4. Be agile and iterative based on stakeholder participation and measurable results
  5. Be tactically and strategically effective with the backing of an authority to act

 

Best Practice in Enterpise SOA

March 2, 2008

What is best practice for Service Oriented Architecture? The work Model Driven Solutions and GSA have done suggests a best practice at the enterprise level.

What this best practice develops is Enterprise-SOA as BOTH a business and technology style of architecture. Enterprise SOA is consistently represented by well defined models that are independent of the technologies that ultimately provide solutions integrating new and legacy functionality. Solutions, at this scale are for collaborative and virtual enterprises, integrated communities and “systems of systems”. SOA must, ultimately, facilitate better business, better mission execution, collaboration and mutual value.

In my opinion, this represents the most central principles of SOA best practice:

  • That the SOA architectural style focuses on how participants work together using services to achieve business value
  • That business services are the driver of the architecture
  • That technology services and business processes are defined to support the business services
  • That both “top down” and “bottom up” concerns must be taken into account in any architecture
  • That these architectures are independent of implementation technologies but can support multiple implementation technologies

This approach has been realized by GSA in terms of several projects, one example is their “Financial Management Enterprise Architecture” (FMEA). This has had several layers of development:

  • A wide-scale enterprise architecture (composed of both SOA and Value Chain viewpoints)
  • A more detailed business architecture for financial management, including business processes and services
  • A “systems of systems” level technology services architecture, based on the business architecture
  • An open source Model Driven Architecture provisioning capability to produce a large percentage of the application from standards based models
  • An open source SOA infrastructure that supports 24/7 operation with redundant, distributed deployment
  • A SOA implementation for one area within this architecture with adapters to COTS and legacy systems
  • Use of the latest modeling, MDA and platform standards

Is this all done and perfect – of course not! There are business, technical and process issues. There are issues with business stakeholders understanding why SOA is even needed (business or technical)!

Is this “best practice” – I think so! Particularly in the government – and a great benchmark for any large organization.

 

Note that a tutorial is being given on this subject March 13th in the OMG meeting near DC, see Model Driven Service Oriented Architecture


Follow

Get every new post delivered to your Inbox.