Test Sidebar Title

Not the solution you were looking for?

Click the link below to submit a support request
Submit Support Request
Check Status - Previous Requests

Knowledge base

Executable Architecture

From time to time an interesting debate breaks out in the LinkedIn group for Model Driven Architecture, over whether MDA will be making software developers redundant anytime soon. They’re discussing why MDA hasn’t become mainstream yet and why it’s taking so long for modellers to take over the world.

For those who aren’t familiar with their proposal, I will grossly over-simplify the proposition as follows (under risk of ex-communication from the group for my heresy):

MDA suggests three modelling layers comprised of:

  • The CIM (Computationally Independent Model) in our case a conceptual model of a business operation
  • The PIM (Platform Independent Model) a logical design that could potentially implement the CIM on “any” given platform
  • The PSM (Platform Specific Model) a physical design of the solution implemented on a particular platform.

These are accompanied by a set of transformation maps to convert from one modelling layer to another, because the OMG doesn’t have a single language that applies at all three layers.

Actually I’ve never seen a working solution of the OMG’s vision and I don’t think it is likely to be taking the world by storm. However, I do think that there is a more relevant question of whether an “executable” architecture is a realistic proposition.

I think that the prospect of an executable business architecture model is not only likely, but actually quite imminent. I’d venture a guess that most of us (at least the ones who still have hair) will see it become a reality in our career-time.

I’m quite certain however that it won’t be based on UML and don’t believe that MDA based transformations of UML could ever lead to a pragmatic outcome. The whole concept of transformation is the Achilles heel of MDA and is fundamentally flawed in my view.

On the other hand, our experience shows that ontologies and semantic technologies hold great potential for executable models. The whole concept of transformation is irrelevant in a semantic model since the conceptual modelling language of the CIM (e.g. RDF/OWL) is entirely consumable by the platform layer so that there is nothing to transform. A semantic model combined with a query layer, an execution engine and a front-end visualisation layer forms the basis for a perfectly viable semantic application.

So how is this an executable architecture? Well the missing link of course is a meta-model for the CIM; in our case the CAPSICUM Framework. CAPSICUM is a domain ontology of a business, providing the foundational concepts and properties for defining a semantic model of a business domain. CAPSICUM further provides behavioural and governance models that articulate the logic and flow of business transactions. Together this provides a complete articulation of the business operation as a state-machine.

A CAPSICUM model is analogous with an MDA CIM, a conceptual model of a business. However, since semantic models can be instantiated, it is only a small extra step to instantiate the elements of a business transaction (eg in a sales process, the attributes of a customer, an order and a product) and to apply the business logic contained in the model to execute the transaction.

Why is this better than what we have now?

Because by encapsulating the logic of a business operation in a semantic model of the enterprise, the organisation creates a new strategic asset, an executable business model, which is technology agnostic and therefore insulates the business from the potential disruption of ongoing technology innovation. We are moving inevitably towards an intelligent digital mesh, where semantic business models plug seamlessly into a real-time cloud of micro-services, block-chains or any other new technology options that start-up innovators throw at us.

The power and potential of semantic technologies are already well understood by many of the new-world technology platforms (eg Google, Facebook, Amazon) but have yet to penetrate the enterprise world. As they do, they have the potential to generate a powerfully disruptive technology shift as enterprises begin to completely reimagine enterprise applications as we know them.

Continue Reading

Decomposing Process Models

The last post The Architecture of Purpose, described how a strategic plan is aligned with an operational plan in a Business Architecture. The concept of an Outcome was explained as the state-of-affairs for Resources in a business domain. Outcomes are modelled as patterns for the properties of Resources.

This discussion will continue to explore an outcome-based Business Architecture model, beginning with the exercise of decomposing business processes to convert behaviour-oriented models into outcome-oriented models.

In 2007 I was on a quest for an executable architecture when I came across an intriguing article posted on InfoQ by Jean-Jacques Dubray discussing the interesting concept of Resource lifecycles. Anyone who knows the CAPSICUM Framework would recognise how influential this thinking has been. I’ve used his example of the job application process many times in discussions on process decomposition.

Process models are behaviour oriented. They focus on the sequential coordination of activities and the logic that links them. For a generation of business analysts they have provided very useful, clear and structured representations of the decision-making that informs sequential behaviour through extraordinarily expressive notations such as BPMN. Many of the brightest minds in our community in recent times have been staunch promoters of process models and to many people BPM is as close to a religion as you can get with a three letter acronym.

So what are the down-sides of behaviour orientation and why would you need to consider anything different? Who would dare challenge their supremacy and risk incurring the wrath of an evangelistic community with such heresy? Is there anything to be gained from alternative approaches?

I like Outcomes. It just seems so obvious that if you haven’t defined what you want to achieve, there’s no point in defining how you’re going to do it. Kicking off a recent process re-engineering project I was surprised by the strident concern voiced by business stakeholders that by automating their manual activities they were going to be mummified in rigid and inflexible process automation. “We’ll record any information you want, but don’t make us have to follow a process”.

Anecdotal evidence and a sample of one isn’t going to convince anyone, but clearly there have been some bad experiences and not everyone is a convert. Stepping back objectively and compiling a list of some of the negatives, here’s what I’ve come up with:

  • As those business stakeholders sensed, the challenge in modelling behaviour is the brittle, rigidity imposed by burying logic and rules into process models. Conditional rules and the sequential flow logic embedded in process models are difficult to access and manipulate by anyone who hasn’t mastered the notation, frustrating business people and stifling flexibility in adapting to change.
  • Decoupling logic from behaviour models has long been recognised as a desirable objective, which Business Rules engines and Real-time Decision engines attempt to address. Delivering on the promise may still be some way off, although an argument could be made that process models are possibly hindering rather than sustaining the potential.
  • Whilst rigid process structures do have some business value in documenting and enforcing highly regimented administrative or financial procedures, they create tedious, bureaucracy for more dynamic business behaviour, which is not necessarily desirable or effective when over-structured.
  • Procedures are actually governance constructs, not behaviour constructs. Procedures represent policy logic (Directives) and yet they are so entwined in process logic that they get mistaken for the same thing. Once procedure rules are modelled into process logic they become trapped, indistinguishable and unavailable for parametric tweaking by the business.
  • Process models are at best a compromise. Process maps and models do not truly reflect the achievement of business objectives with their focus on “how” rather than “what”. Business stakeholders are measured on what they achieve, with a lot less emphasis on how they do it. A sales team is not measured by how efficiently it follows the sales process, but by how many orders are booked. Organisations have been managing by objectives for decades. Objectives are Ends, not Means; measured by results which are tallies of Outcomes. Processes are Means and do not recognise or provide any tangible representation of the Outcomes that management is concerned with.
  • The typical business stakeholder gets little practical value from process models other than as a documentation of business procedure, as discussed. The effort in developing process models is largely targeted at informing technology teams how the business works.
  • However in a similar manner, process models aren’t particularly useful artefacts in the development process since they don’t reflect the way in which system code is developed. If they did, the BPMN constructs of gateways and events should map directly to native constructs in an object-oriented language such as Java for example. In fact, “implementation of BPMN is difficult and costly to achieve” (Durocher, 2011). Try giving a BPMN process to a developer and saying “Build this”.
  • Modern rest base API’s are based on the design principals of decoupling, encapsulation of logic and statelessness of services. Processes represent the antithesis of this philosophy. Processes impose tightly coupled dependencies between activities, have sequencing logic disseminated throughout their structure and are entirely state-full. The resolution of this dichotomy was achieved in service oriented architecture through service Orchestration and Choreography, which does go some way towards decoupling process logic from process activities (services) but which still relies heavily on sequencing and flow logic rather than state-based logic.
  • Perhaps most importantly, almost any software application is designed around a data-model. Yet a process model doesn’t have any construct for identifying or describing the data that is necessarily produced, consumed or transformed in its execution. That surely is a glaring omission in BPMN.

There are many other well-articulated discussions that explore this question, including the article referred to earlier. So what is the alternative? How do you build an outcome-oriented model and what do we mean by decomposing a process. I will use the example advanced by Jean-Jacque to illustrate the steps.

The following is his BPMN model for a job application process. It provides a concise articulation of business roles (swim-lanes), their tasks and activities (boxes) coordinated by the logic of gateways (diamonds) and events (circles) that connect the boxes. We’re going to decompose this process into more granular, reusable constructs and decouple the logic to make it more accessible for manipulation.

We start by looking for Resources, the things that will evolve in the process recording the outcome states of this endeavour. We know that BPMN doesn’t model things (nouns) it models activities, which are verbs, but they act on nouns. Identifying the Resources in a process model is simply a matter of looking for nouns. In this part of the Recruitment model the activities operate on three core nouns namely a Job Application, an Interview Schedule and a Job Offer before moving on to Hiring. In Step 1 below, Resources are identified in Red.

1. Identify the core Business Objects (Resources)

From the activities carried out each of these Resources we can piece together the Outcome states that represent the lifecycles of the Resources. Outcomes are shown in Green in Step 2 below:

2. Identify the Resource Outcome Lifecycle

We can now remove the complexity of the rules, events and logic from the model as shown in Step 3

3. Remove Sequencing Logic

Simply reorganising these states into an inventory of Outcomes reveals a very simple and clear depiction of the Resource lifecycles.

4. Reorganise into an Inventory of Outcomes

We know already that each Outcome is achieved by an Activity, especially and intentionally designed for that purpose, so can add those in Step 5

5. Attach to the Tree of Undertakings

From the swim-lanes we already know which Roles are needed and can deduce the subject Resources (or Parties) that they will capacitate, as shown in Step 6:

6. Identify the Roles

These four constructs comprise the first four cells of the CAPSICUM Framework, with Resources, Outcomes and Roles representing the Domain Model Scaffold. Undertakings are easily grouped into Capabilities and the tree of Capabilities forms the Business Architecture backbone, off of which the models all factored.

The Domain Scaffold cells are highlighted in their respective colours in the CAPSICUM Business View overview below. The uncoloured cells represent additional levels of detail and logic that are incrementally added to the Business Architecture models in the subsequent steps.


Continue Reading

What is Enterprise Architecture?

In hindsight it was inevitable that the analogy would be eventually made between the practice of architecting buildings and what we do when we plan and manage enterprise systems. Zachman is widely attributed the honour. Apparently it was he who first recognised the mutual affinity for the conceptual and the same natural instinct to explain everything with a felt pen and diagrams of boxes and arrows. Given the sense of nobility to the title it was soon commandeered, to the point where it appears that real architects have since abandoned it and now aspire to be “Grand Designers”.

In IT, the appeal was universal and it wasn’t long that we had an architecture for every job description. The Network Architect, Security Architect, Integration Architect, Information Architect, Solution Architect and of course, the one to rule them all, the Enterprise Architect.

With architectural graffiti being sprayed across every nook and cranny of IT, somebody inevitably tagged the Enterprise Architecture; and ever since it’s sat there, puzzling us like the indecipherable calligraphy of teenage spray paint.

What is it? Who owns it? Why aren’t they doing anything with it?

What exactly are the concrete artefacts that comprise a business architecture? How do they align with all the other charts and diagrams that illustrate an enterprise architecture? Is there a standard model or a recipe for building one? Where does it begin, where does it end and what should it contain? These are all very good questions that emerge just as soon as one starts to scratch the surface.

There is a disturbing question here, since one would think that the business perspective should surely be the pinnacle of the architecture food chain. So if we haven’t got theirs worked out yet, what on earth have the rest of us been architecting?

Truth is that to date the focus has all been about mapping out how technologies talk to each other without much consideration for what we need to do to achieve our business goals and strategies and designing the most efficient, consistent and scalable way of doing so. Since we have rarely produced a well-crafted model of the business, perhaps this explains those wild accusations of enterprise architecture as a myopic and self-serving competency.

So, back to the question. What is a enterprise architecture?

A business architecture is a strategically aligned representation of a business operation and the ecosystem in which it operates. A enterprise architecture model explains what the business needs to do to achieve its desired results. It facilitates alignment of the strategic plan with the target operating model by making explicit the structure, execution and governance that guides the business operation. It is a roadmap for getting from strategy to execution.

The strategic plan for a business explains what it intends to achieve and how it plans to achieve it. The enterprise architecture model elaborates on that with a detailed decomposition of the organisational capabilities that the business will need to address the plan and assembles the capabilities into value-streams explaining how the plan will be executed.

Strategically aligned business capabilities are then mapped to the people, processes, information and technology in the target operating model, ensuring alignment between what you plan to do and what you actually do.

Importantly the enterprise architecture is a blueprint for change. Every business is in an inevitable state of transformation to keep pace with the ecosystem that it operates in. As a detailed model of the current state of the business operation, the enterprise architecture is a crucial element in planning for change.

Finally, we should impress that enterprise architecture is a top down exercise, conducted completely independently of the constraints of existing technology platforms. Rather, it will always be an essential precursor to the effective architectural design of strategically aligned systems. Bottom up architectural approaches that focus on the nuts and bolts of technology plumbing are a major contributor to the great divide between Business and IT in the first place.

How did we ever fall for that sales pitch that our businesses should adopt the “best practice” inherent in packaged applications? Unless you’re talking accounting software, PHOOEY!

Every great architecture starts with business.

Continue Reading