Business modelling with domain specific languages

If one wants to make business modelling effective it is often useful to use domain specific modelling languages. If for example one is modelling an airlines it may be useful to model with concepts such as: passengers, cargo, baggage, flights, tickets. One could of course use generic business/technology concepts for these e.g. organisations or people (customers), products and services (e.g. flights), contracts (e.g. tickets) etc. And people do try and use abstractions of abstractions e.g. actors, objects., tables etc.

Effective modelling in a business language is also necessary for the establishment of reuseable patterns.

The further one abstracts the more difficult it is for the people to understand, and to build the intrinsic knowledge of the domain into the model/artefact. This is why you won't see many good documents written by business analysts using overly abstract concepts (or any executive level documents) e.g. actors, objects, rows, tables etc.

What one needs ideally is an environment that allows domain specific semantics to be quickly instantiated - inheriting from abstract objects as appropriate i.e. passenger is a type of person (has name, address etc.), to be able to model using these semantics and relate all modelling concepts together when it is useful e.g. domain specific, generic business/technology, and various technology specific abstractions.

These domain specific languages are aimed at people interested in the domain (the business) i.e. business users and analysts. They would be used in preference to the "unified" and technology oriented languages foisted on the business by the development community.

Obviously design oriented languages should be used by systems' designers (e.g. UML, BPML, ER, XML etc.). As they form a useful common abstraction point between the technology specific languages used by developers (there will often be many of these).

These languages act as bridges between the business domain specific languages that most appropriate for business modelling and the technology specific languages that are used for construction. They provide an articulation point between the business domain and the technology domain. This articulation point is required: to allow design for construction with a heterogeneous/open technology set i.e. where there will be range of technology specific implementation languages (many of which may not have been selected/determined when the business modelling is undertaken) ; and to allow aspects of design modelling to transcend the specific technology implementation selected. Design involves decisions regarding what implementation technologies to use and therefore one does not want to prematurely lock the design thinking to implementation (unless one is a technology product vendor seeking to "capture" the customer). If one was designing a beam - one would often want to know the characteristics of the beam (by modelling) before determining if the beam should be wood, steel, concrete, a truss etc. or a particular brand of style of steel beam (i.e. in this case these are the implementation technologies).

Even organisations with a strong historical alingment to UML (and MDA whose current implementation is unfortunately predicated on UML) are moving to DSL to overcome the complexity (and unnecessary abstraction) that UML involves e.g. Borland is adding domain-specific language capabilities to Together package for application modeling to enable project teams to build model notations aligned with a business domain. This is not to say that UML has no place - it is fine for technical people to communicate amongst themselves - you just can't reasonable inflict it on non-technical people (or pretend it is well suited to capturing business requirements).

See: UML not suited to describing the architecture or an enterprise

Business and IT Transformation

The term "EA" has developed some unfortunate connotations e.g. it has been confused with "technology architecture", "systems architecture", "solution architecture", "software architecture", "business process modelling" etc.

This is reminds one a little of the famous strong of the "blind men describing the elephant".

If one uses the analogy of town planning - it is a bit like confusing town planning with: architecture, electrical installation, landscaping, interior design, plumbing etc. When asking for a tool selection to support townplanning - one is then asked if it has a electrical load modelling capability; hydrological modelling capability; a lighting model for examing interiors, or a CAD tool for drawing beams [see http://ea-in-anz.blogspot.com/2007/09/ea-and-analogies-with-built-environment.html]

In EA at present one is often asked if it the EA tool is a CASE tool (ER modeller) or process simulation tool - and what this illustrates is that the person asking the questions does not a good grasp of what EA actually is. [see http://ea-in-anz.blogspot.com/2007/09/ea-cant-be-done-with-document-or-case.html]

EA also is often seen as some ivory tower activity that at best produces lots of large complex documents (that always out of date, and that are of little value to anyone other the authors) - mainly because EA is done in the wrong way.
[see http://ea-in-anz.blogspot.com/2007/08/myth-of-heavy-weight-ea.html]

It may well be that the pragmatic way around this is to abandon the term, and the
focus on the end goal which is business and IT transformation.

UML is not a language suited to most aspects of EA

(prompted by discussions with EAs and "How UML is Used")

UML is often one of the first words that comes out of IT people's mouths when one discusses EA (in a bizarre attempt at logocide one organisation evens call its UML modelling tools Enterprise architect).

UML may be very useful, but not for most aspects of EA. This is because most of EA has little to do with OO modelling oriented at OO development (or SW development and per se) and because UML is just not effective for communicate with most of the business (i.e. not technical people).

The analysis that needs to be done in EA is not really related to: the different states that objects can exist in, the messages that objects used to communicate, or low level technical "use cases". Obviously an EA needs to consider scenarios of use (how things are used in different situations by different roles or systems). And one could use the very oddly named "use case" for this, however many other mechanisms are available usually better suited to use in EA. In my experience the quickest way to alienate most business people is to start of by using abstract terms like "actor", or talk to them Swedlish. Most people in the business prefer natural business concepts like: business process, business role or organization, etc.

That people attempt to apply UML to enterprising architecture probably indicates the mistaken belief that EA is somehow an extension of software development - and goes a long way to explaining why some many EA initiatives fail.

There are various aspects of detailed SW design oriented analysis that we may wish to relate to from an enterprise architecture or we may wish bring together for analysis the disparate views of various development silos e.g.
- process orchestration development views which use BPEL that may relate to BP models
- object development views which may relate to UML models
- data development views which may relate to ER models
etc.
This is more in the solution architecture rather than enterprise space. What an EA can do is bring together these disparate silos. For example we could consider the relationship between a business process or a business role/organization, and a business application (and elaborate that relationship using UML - if it really added value). But for most people getting a canonical list of business processes or business applications would be a great starting point - rather than elaborate great detail one interaction

We could also consider the broader issue of the utility of UML in capturing requirements per se. UML is also often also one of the first words that comes out of IT people's mouths when one discusses business requirements.  This is mostly the case when IT people with a SW engineering background are involved. Or when executives want to show they an "in" with technical people by using their arcane terminology,

UML not useful for most, if any, aspects of business requirements management. Business requirements may result in software development (the majority will not). Of those that do require development only a subset will require OO (e.g. others may require BI). Often when development is required it will be outsourced or done under contract. What the business needs is boundary of responsibility that allows those solutions elements delivery to be assessed.

By way of analogy. If one has transport requirements - one doesn't to be asked what use case of a brake pedal is. One wants either a transport solution (streets, tracks and trains, roads and vehicles, ships and ports), or a services (e.g. buses, taxis), or possibly an in-house asset car, a bike, a plane. In the rare circumstances where a car is engineered for a client - it would be a very brave (or foolish) client indeed who would try to specify it, or its components, using Use Case, Sequence diagrams.

In "How UML is Used" by Brian Dobing and Jeffrey Parsons - it seems reasonable to assume that as the data references in this article is gathered from UML practitioners/clients they are not unreasonably prejudiced against UML. What bemuses me is that the authors - despite the facts in front of them - doesn't seem to just say "UML is not great for client facing requirements capture" or for communicating with non-technical audiences. This doesn't mean UML may not be great for technical communications e.g. between designers and developers.

What can we learn about "How UML is Used" regarding requirements capture?
- UML may be too complex for clients (no kidding) and those who are not technical (i.e. who don't want to participate in development).
- UC are not thought that good for communicating with clients (business people)
- Clients (business people) don't want to review the artifacts beyond UC narratives (and why would they, when these are really development/developer oriented models)?
- UC diagrams are rated as least useful in providing additional information to developers.
- Despite the above developers, undeterred, seem to believe that UML diagrams can be understood by clients?

Contrary to claims in the popular literature, developers appear to believe that UML diagrams can be understood by clients. 87% of respondents rated UC Narratives as useful for "verifying and validating requirements with client representatives on the project team.", but when asked whether the UML facilitated communication with clients, 55% said it was at best "Moderately Successful."

Domain specific business languages (or Enterprise specific languages) may be a better answer. To instantiate these dynamically so they are available for modelling, one needs a metamodeller.

EA requires an ability to communicate on many subjects with a diverse range of stakeholders. Selecting an arcane language oriented at object oriented analysis is unsuited to the task i.e. both the semantics and the notation are a poor fit for the vast of the information used to describe an enterprise.

If UML struggles to capture the requirements for project in which development undertaken (i.e. to act an effective mode of communication) - surely people can see that if the task is describing an enterprise (where development is not the major goal i.e. it is a necessary evil) - it is unlikely to be a good fit.

Of course long before this Anthony J H Simons, Ian Graham wrote about: 30 THINGS THAT GO WRONG IN OBJECT MODELLING WITH UML 1.3. In this the authors catalogue problems experienced by developers, using various object modelling techniques brought into prominence by the widespread adoption of UML. Developers still seem to create inordinate problems for themselves by pursuing unproductive development strategies that are apparently fostered by UML. This article shows how the biggest problem by far is cognitive misdirection, or the apparent ease with which the rush to build UML models may distract the developer from important perspectives on a system. This problem is more serious than the outstanding inconsistencies and ambiguities which still exist in UML. While UML itself is mostly neutral with respect to good or bad designs, their are consequences of allowing UML to drive the development process.

The cognitive misdirection problem is more serious when UML is applied in domains other than OO design. In these case the pursuit of unproductive strategies oriented around UML can only consider "the triumph of hope over experience" (Samuel Johnson).

See www.semanticprecision.com for a better solution.

The myth of "heavy weight" EA

There is a common myth that maintaining an effective EA introduces a lot of cost to the Enterprise. An EA implemented in the right way reduces the level of effort and cost in an enterprise overall.

An effective EA needs to be supported by the right tools, and the right changes in associated processes (each of these processes in turn becomes more efficient and accurate) and be comprehensive in the set of stakeholders it supports.

A "Light weight" EA - where a superficial and partial set of information is assembled in the traditional way (i.e. without the right tooling, and without changing the touch point processes) may suit "light weight thinkers" - but as they fail to deliver substantial value and they add additional cost - they don't make any sense.

Establishing the changes in an enterprise that will allow an effective and complete EA to develop (and establishing the tooling, and changing associated processes) does have a cost but this cost is comparatively small if led from the right level within the enterprise, undertaken over a period of time (i.e. most cultural change is hard to effect quickly).

By way of one imperfect analogy - books and libraries
Assume your current strategy for managing books (i.e. knowledge - putting aside for now the fact that documents - especially in narrative form seldom make the semantics explicit, or relate knowledge in one book explicitly and atomically to knowledge in another book) is to leave the books scattered all over every office (and this is the form i.e. documents, and is the strategy essentially advocated at present; for most the design/governance artefacts associated with an enterprise).
Most people would find it quite difficult to find the correct information on most subjects, and if they wanted to record new information about subjects so that others could find it they would not know where to put it.

Say a proposed strategy is to establish a library function e.g. a classification system (Cf Zachman's framework), some places (physical or virtually) and some simple processes (that you would like people to follow). Now the actual cost of finding knowledge on any subject (i.e. what is said by a range of authors, with different perspectives) is reduced, and knowledge on subjects can know accrete in a natural way. Yes there is a set up cost.

A problem with this analogy is that most of the documents created in an enterprise are created by their authors for a very small and select audience (which in itself is odd), whereas most authors of books would ideally like their readership to be as broad as possible.

Another imperfect analogy - maps and the environment (built and natural)
If your current strategy for managing information about the environment (from rivers and mountains, to buildings and reticulation systems) is to leave documents scattered all over a wide range of offices/enterprise (and this was the form that the various stakeholders used until very recently). And a proprosed strategy is to establish a mapping function e.g. a classification system (a co-ordinate system, or a map projection), a collation mechanism and processes. The actual cost of finding out about any areas is reduced, and knowledge (on all areas) can accrete in a natural way (i.e. as the plans on buildings, cables, new information on soil types, etc. are deposited). Yes there is a set up cost.

No new information needs to be created - and in fact the effort associated with creating meaningful new information is reduced (e.g. it is easier to design changes if I can see clearly what already exists - buildings, cables, geological structures etc.) at the start of the exercise - rather than as I start construction (which is the ICT industry's approach).

Many artefacts are created by a function or unit for a very specific purpose and for a very small and select audience. The artefacts are usually focused on a narrow task (usually related to some delivery and/or construction activity), and specific timeframe (e.g. usually the immediate future). They are not oriented at: the ongoing maintenance, the effect on others, their discovery in future, the eventual replacement of what they is being delivering etc.). Governance (town planning functions) is slowly overcoming the impediments that the various engineering and cartographic specialists put in the way of this knowledge base by organising and sharing that knowledge.

SOA must be underpinned by better management

Most people know SOA is widely over-hyped (mainly by vendors seeking a new label to sell last years goods under, and ICT people who see a new set of technologies they can focus on rather than engage with the business). How on earth can we move to a more sophisticated, atomic, externalised, real-time view of services (lets forget about technologies and standards for now) - when the current management of services - which are simple, large-scale, mainly internally controlled, and seldom adjusted in real-time - is just typically pitiful (from requirements, through design, to implementation, operations and measurement).

In a CIO presentation on SOA in early 2005. I discussed the business drivers and technology enablers for SOA, the design challenges (perennial and new). It was drowned out the superficial presentations focused on irrelevant discussions around a plethora of technologies and standards.

I identified some things that make it hard e.g.

• absence of a well articulated technology vision
• tightly coupled, poorly bounded, systems producing fragility and insecurity
• technical fiddling with OTS components so that systems overall are expensive to maintain
• poorly managed outsourcing [i.e. the management of services]
• orienting technology architectures around systems/vendors/products/technologies rather than around the business and standards
• descriptions of the business that were incomplete, incoherent, inconsistent, inexplicit.

I suggested that the challenges are largely the same as they have been – but failure may become harder to hide (i.e. perceptions of the quality of businesses may be based on how well their systems perform).

That SOAs don’t present many overly difficult problems to well architected and managed enterprises, but that SOAs may be less forgiving to doing things in ways that have worked in the past (though they are not best practice).

To support my call for more professional and better management of complexity - I quoted British computer society "A striking proportion of project difficulties stem from people in both customer and supplier organisations failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry... Whilst the most pressing problems relate to the people and processes involved in complex IT projects, further developments in methods and tools to support the design and delivery of such projects could also help to raise success rates. In particular, basic research into complexity is required to facilitate more effective management of the increasingly complex IT projects being undertaken..."

To point out how little has changed I referenced what was said on architecture in a IBM systems journal from 1999:

• “Today, the most common model for solution development is based on an approach that we call ‘heroic’ ”.
  
• Goals: contain costs and risks, providing timely, adaptable, and customizable solutions.
• Challenges: complexity: driven by new technologies/standards; legacies; many applications/services; unique customization; external relationships (i.e. business network) change: a high rate of both business and technological change.
• Suggestions regarding the solution: patterns: a standard framework to support creation, reuse, and maintenance of design assets; discipline applied: to allow practitioners to base their development on patterns; reuse: of proven building blocks, applied systematically to enable asset-based solutions optimized to business goals. focus on: component topologies/interactions & management of: security, systems, performance; combine: HW, SW, products, assets, and services; establish: business reference models, default infrastructural templates/frameworks, contextual map for cataloging assets and knowledge, clear methods for making decisions
  

To indicate my dispair I quoted Hegel "what experience and history teach is this - that [we] have never learned anything from history, or acted upon any lessons they might have drawn from it". Though I would rather believe William Blake "Truth can never be told so as to be understood, and not believed"

Justifying architecture and strategy

There are always challenges in valuing, and therefore justifying, good (or often any) design, strategies, plans. The problem lies in a number of areas e.g.:

• Challenges with counterfactual analysis: in most situations (enterprises, buildings, cities, endeavours), one can't easily compare the result of the designs/strategies/plans that was actually taken - with other hypothetical designs/strategies/plans that could have been taken. People either need to intuitively value sound well reasoned designs, strategies, plans - or not i.e. the ROI is either obvious or it is not. So there is no point of comparison.
• Self-interest: This can militate against sharing knowledge. Knowledge is power. This can be seen in many professions to a greater or lessor extent. If ones shares and/or make available the knowledge one has (or the basis of a decision), one may diminish ones value (as a holder of knowledge), and become open to criticism (e.g. regarding the veracity of the data or the soundness of the analysis).
• Secrecy: Sometimes one does not wish to disclose a strategy/plan. Often the downside of secrecy is that people in ones own team or side, don't understand what should be done, why, when etc. (i.e. the benefit of secrecy is outweighed by its impact on efficacy).
• Thinking is intrinsically difficult: These things (strategy/design/planning, and modelling) are often quite difficult to do well i.e. they require quite a lot of thought. To make matters worse the result can be seen, with hindsight, as trivial and not justifying the effort required.
• Thinking takes time: It is always quicker just to act
• Thinking costs money: As results may be seen as trivial e.g (F = M x A) and could not be worth justifying the effort.
• Future is someone else's problem: That what is constructed is a poor fit, doesn't last, is expensive to operate, expensive to change or adapt is often not the problem of the initiator, the initial designer, or the builder (and perhaps the initial user).

These issues can be seen all areas of life e.g. social planning, cities, buildings, cars, and of course businesses and Information and Communication Technology (ICT). ICT is particularly bad as it has not yet matured into a profession (where people have the requisite learning, training and discipline and profess a code of ethics).

People wishing to ensure better strategies, designs and plans, need to look for others who:

• Intrinsically value better strategies, designs and plans, and can consider the future.
• Can overcome self-interest of knowledge holders and know what must be kept secret
• Know thinking is difficult, takes time and money and are prepared for the effort.

Michael.

James Rogers comes to Australia

We are please to have James Rogers, the Chief Marketing Officer of Troux, visiting Australia in August.

James recently authored the cover story of Architecture and Governance magazine, "The Evolution of EA".

He is speaking at breakfast sessions in Sydney on Wednesday 29th August 2007, and in Melbourne on Thursday 30th August, and his subject will be "The State of EA in United States and Europe".

If you are interested please contact us on +61 2 9900 4100 and we will give you the details.

Guy

Welcome to EA in ANZ

Welcome to this first post on EA in ANZ.

This Blog is intended to share information and ideas on the practice of Enterprise Architecture, and be a source of information for the user group of the Troux / Metis EA toolset.

We will endevour to keep people up to date with the latest developments and share ideas, techniques and other interesting bits of information as they come up. We encourage you to subscribe to the RSS feed of this Blog so you can see when we have posted something new.

Guy & Michael