Cory Casanave's Weblog

Achieving an Architecture Ecosystem

Cory Casanave — Fri, 15 Jan 2010 19:40:33 +0000

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

Cory Casanave — Thu, 17 Dec 2009 22:19:15 +0000

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

Cory Casanave — Sun, 09 Nov 2008 19:47:47 +0000

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;

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

Best Practice in Enterpise SOA

Cory Casanave — Sun, 02 Mar 2008 06:09:02 +0000

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

The open source road for making technologies pervasive

Cory Casanave — Wed, 13 Feb 2008 16:31:10 +0000

Is open source the right road? This is not an easy question. I can relate it to my own experience in that I was in the commercial product business (for 20+ years) with tools and infrastructure so I fully understand the challenges and questions of making something and having it succeed as a commercial product. On the commercial road there is the huge up-front investment combined with concerns about small companies delivering crucial infrastructure, marketing costs, long sales cycles and the risk of being eclipsed by open source. On the open source road there are all the business model questions, what is open, what not, under what terms to support a realistic business model.

So this is where we are going and why; As I said, I have had commercial products and was along the way to developing more. It became increasingly obvious how hard that direction would be to sell, fund, market etc. In that we are trying to be part of making an emerging technology pervasive, we also look at the potential for a “big win”, something that really has an impact in the marketplace. So our conclusion was that without (at least) $40 Mil it was a non-starter, even with such funding it is risky. The open source road looks better. The only way what we are doing may become a “happening” in the industry, is open source – if it becomes a happening, we will find the ways to profit from it.

The odd fact that seems to be now proven is that by giving it away it doesn’t mean you can’t also sell it!

So we have done a reversal on “I.P.”, anything we do (or use) we want to be open source so that we have the best chance of being behind something that is pervasive and compelling. We call this “funded open source”, we are not in it for fun and games. The business model includes funded development of assets, related projects to apply the technologies, supported commercial versions, training and “community income” from a (potentially) active community. Of course there are also buyout options. We are not opposed to commercial products at all, and see a lot of opportunity in helping to promote products and services that work with the open source base. Part of what we are trying to build-out is the capability for fully executable models – models that become applications very easily. There seems to be a great opportunity for open source models and both open source and commercial application components built on these models.

Then there is also the business model of commercial licensing – using an open source license that is sufficiently restricted (like GPL) that commercial users must pay. We have not yet done this, but is something we are thinking about – I am interested in peoples thoughts about this.

So this is why we are starting “modeldriven.org“, it is not really active yet because we are just getting to the point of having sufficient open source assets – but we will be announcing some very soon. Modeldriven.org will focus on embracing all things around models – this includes “MDA” (Model Driven Architecture) kind of models and the semantic web. We want open tools, infrastructure and open domain models (with the corresponding executable applications). A lot of this is being funded by the visionaries at GSA (www.osera.gov) like George Thomas and Richard Murphy.

So this is why we are going open source and would be interested in others thoughts.

Introduction

Cory Casanave — Sat, 02 Feb 2008 17:10:51 +0000

As a short introduction, I am Cory Casanave, president of ModelDriven.com and founder of ModelDriven.org. I have been active in the software and architecture communities since 1990 and the software business since 1978. My focus has been on architecture and distributed systems. Architecture, as I use it, applies to business, enterprise, I.T. systems, information, processes, etc. A common theme through all of my various projects, roles and companies has been better architecture and making those architectures “real” with technologies. This has brought be to Model Driven Architecture, SOA, BPM, Metadata management and the semantic web. We are doing this in the open source community to make them pervasive. These are intended themes of this blog.

As I have been active in communities for years, I really should have had a blog sooner, but alas, I am just experimenting with it now. So this blog is, for now, an experiment. Perhaps together we can make the experiment work.!