During a conversation last week with a Forrester senior analyst (Dave West) from the UK, I learned about a new term and a new industry "movement" - DevOps. He said that there has been recent interest in this topic which combines, both literally and figuratively, the terms "developer" and "operations". So of course when our call ended, I did some searching on the term and learned that there is indeed a fledgling "DevOps" community of developers and sysadmins who have recognized - as many of us - that applications should get built with full knowledge of the operational environment in which they will run. This group of primarily UK/Northern European IT professionals has collaborated on recommendations to remove some of the silos between those who build and those who run applications. This represents a cultural change as much as a need for integrated teams and processes. Two years ago in this space I spoke of the need for developers to use ITIL practices "to understand the real impact of new applications on the run-time environment and how they need to be designed differently for the complex, distributed environments we have today". Perhaps not much has really changed, but at least the conversation has broadened.
The DevOps community sees agile and lean teams better suited to collaborate and drive DevOps thinking because of their matrixed approach, but I don't see why two-way communication, which is both the bridge needed and the current barrier, should be limited to small teams. We need to see push and pull of information equally from both developers and operations. Silos within the IT organization or even when traditional outsourcing and multi-vendor partners are engaged are challenges but not insurmountable.
Just as one example, when developing a web application I really do need to understand the capacity (network, servers, storage, database) of the current run-time environment as well as the security levels, and I need to work with both sysadmins and service management personnel to have them understand the service level, security and run-time requirements, work out conflicts, and also engage them as necessary for integration and other testing. EDS had the right idea with an initiative called Designed for RunTM that has continued to evolve towards what I believe the DevOps folks envisage, but there is still work to be done.
I do really agree with the recommendations of the DevOps gang that a multi-disciplinary approach must be taken between developers, testers, change and release management, and operations engineering groups such as system administrators and those who manage system capacity and availability. They suggest that team members might gain expertise across the divide. Understanding the best practices from both CMMI and ITIL would help, as well as having the IT skills and experience to go along with them. I've studied this "CMMI & ITIL" process integration area fairly deeply and have spoken at several conferences on the need for integrated application development, service management and infrastructure engineering processes. Drop me a line if you would like to discuss further or pick up a presentation.
UML (Unified Modeling Language) provides a powerful capability for modeling software systems. The various modeling elements and views, along with an extensibility mechanism, can be applied for modeling other systems. So why not use UML to model any system? Users would only need to buy one modeling tool, and the market for UML tools would be expanded.
Standard extensions of UML for specialized applications are called "UML profiles." OMG (Object Management Group) has defined a number of UML profiles. For example, there is a UML profile for modeling physical systems called SysML, a UML profile for modeling software development processes called SPEM (Software Process Engineering Metamodel), a UML profile that extends UML for specification and integration of services called SoaML, and a UML profile for DODAF (Department of Defense Architecture Framework) and MODAF (Ministry of Defense Architecture Framework) called UPDM.
A UML profile can be imported into a standard UML tool to create a specialized modeling environment. UML tools support views (graphical displays) that are appropriate to a variety of modeling applications. The extensibility mechanisms of UML enable existing UML elements to be adapted as new types of model elements and attributes. While a UML tool may be able to support useful diagrams, in the long-term users will suffer from a limited modeling capability.
There are three basic limitations: (1) the UML modeling elements were designed to represent the concepts of a software system design, (2) the graphical representations are not designed for most effective human understanding of the models, and (3) a UML tool does not provide the computational support for structural consistency and functional analysis.
One of the problems encountered in the design of a UML profile is the design baggage that restricts the use of UML elements. Design of a UML profile (a specialized language) requires deep knowledge of the design of UML in order to work around these restrictions. The result is a compromise that provides a less than ideal representation of the problem domain. The semantics of the profile are in the profile documentation and minds of the users. The tool only reflects the semantics of software design.
UML does not provide good quality graphical representations for modeling software, and this does not get any better for UML profiles. An excellent paper by Daniel L. Moody, "The Physics of Notation: Towards a Scientific Basis for Constructing Visual Notations in Software Engineering," refers to UML for examples of the ineffective use of graphical notation. Users should be able to quickly associate the graphical representation of a concept with its semantics. In many cases UML makes very limited use of visual variables, thus obscuring semantic distinctions, and in many cases combinations of these variables create complexity. For example, combinations of three visual variables (shape, brightness and texture) are used to distinguish 20 different types of relationships in a UML class diagram. In a UML profile, a text label is often used to identify a concept. Text requires less efficient, serial human interpretation (reading) while distinctions using graphical shapes are interpreted through parallel, image recognition. As a result, good graphics make it easier and faster for users to grasp the meaning of a diagram.
Perhaps the most important limitation of a UML profile is that the modeling tool does not provide computational support for structural consistency and functional analysis of the model. Enforcement of structural consistency of the model using a UML profile is based on consistency of UML software design models.
A good modeling tool will help the user develop a consistent and complete model. Furthermore, a robust tool will assist in the analysis and improvement of the model. For example, BPMN 2.0 (not a UML profile) defines a modeling language for specification of business processes. This includes modeling of executable processes and choreographies-interactions between participants supported by their executable internal processes. A good BPMN tool will support analysis of compliance of an internal process with the requirements of interactions specified by a choreography. A robust tool might also provide simulation capabilities to analyze the flow of business transactions.
These functional capabilities are not defined by the standard, but will be developed as differentiators by the modeling tool vendors. Addition of such functional capabilities for a UML profile would require implementation of functionality that may not be consistent with the use of the tool for generic UML. The resulting profile language would still not be the best representation and visualization of the problem domain.
The development of UML profiles may provide a quick and cheap solution to modeling new problem domains, but, in the long term, it provides less effective domain representation and visualizations, and it undermines the market incentives for development of functionality that improves modeling efficiency and the quality of results.
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.