Business processes and systems processes

When we describe a enterprise there are a number of perspectives we can take e.g. those relating to:

• offerings: products, services i.e. how we make money
• markets: sectors, customers, accounts i.e. who pays us money
• behaviour: functions, processes, etc.
• decisions: strategies (decision on how achieve), policies, rules, etc.
• knowledge: information, data, etc.
• communications: messages, message details, etc.
• organisation: unit, role, posotion, person etc. (who do, know, communicate, etc.

Where the enterprise is enabled by rigid systems these things will often be represented within the systems. Systems oriented people therefore have perspectives on these things that relate to their need to implement systems. There is a tendency in ICT oriented people to assume that these implementation and systems specific views should be used at higher levels for business planning, transformation and governance.

These low level implementation specific views are necessary when implementing specific changes to the details - but most of governance, transformation and planning takes places at a higher level.  

This slide show gives a perspective on the issue from a process perspective:
http://www.slideshare.net/billpoole/eba-and-bpm-7510328

Technology vendors with their huge marketing budgets have continually spruiked the languages and methods associated with implementation in order to promote their technologies (which obviously need to be implemented). With no equivalent countervailing level of promotion for higher order views of enterprises there is tendency for these technology driven methods to have a preternatural dominance. For most technologists in businesses - the specific business they are in is a transient - the technologies are the things are really attached to so they also gravitate to methods attached to technologies and technology outcomes rather than the business and business outcomes.

Tube Maps

Many organisations are seeking ways to better express and analyse the essence of their business architecture. The business architecture and desired changes to the business architecture are the key drivers of business transformation. Many have: capability Maps; lists of business functions, business/functional reference models, and a profusion of details in business process models (which describe in great detail the specific steps but can not readily present a useful overview). They may also have value chain views that focus on an area, product, offering. Many of these models in turn relate to the technology architecture.

Tube Maps can be used to communicate the essential aspects of the business architecture i.e. how enterprise operates as a whole on in a specific area. These views can then be used as a lens to better understand:
planned transformation, gaps, issues and opportunities. They fill a gap between capability maps (which have no concept of flow); value chains (which focus on specific narrow flows, but not organizations or enablement); BP models (which are detailed implementation oriented views with information that is important for implementation, but have too much extraneous detail for most audiences/purposes).

Tube Maps are selective in what present, often tending to focus on unique and value generation rather than internal governance and operational processes (i.e. as these process are usually fairly generic and dealt with by COTS applications). Tube can automatically generated using our methods and solutions leveraging data held on capabilities, functions, processes etc.

In a funny way it is kind of amusing all the noise about BP models (which are of course implementation specific - with their specific sequencing, roles etc.) and capability models - without any really useful discussion on what visually fits between the single capability map and the hundreds or thousands of swimlane diagrams.

Parallels can be seen in the existence of thousands of ER models and table - but no really clearly communication information models.

So what we might have is:

• Business Capabilities - 100-200 elements (usually structured in a 2-3 level hierarchy - which we present in capability maps, landscape/matrix maps etc. Often just showing the top couple of levels. These are exist independent of any implementation they are things we need to be able to do.
• Business Functions - 500-3000 elements at least one function (usually more) for each Capability (and vice versa). These are largely implementation agnostic (i.e. exactly: how, who, when, where, etc. will change).
• Business process models - 5,000-10,000+ elements, which elaborate one or more functions, are implementation specific, often presented in swim lanes (ideally surrounded by context - who, how, why, etc.)
• Use case - which elaborates the relationship between a BP element and a system/role (either via ICOM or direct). These are obviously not just implementation specific but really engineering specific views to describe the expected behaviour of systems for design or testing.

So it looks something like:

• Capabilities - Travel around city and country side 
• Functions - Go shopping, Take children to school, Go to from/work  
• Process - Go Shopping - Get in car, back out of drive way, drive to shops [navigation system has details], ... stop car, park, shop, pack,  .... drive home, ....
• Use case - stop car - break pedal - press on the break pedal (after precondition of stop pressing on accelerator) and car come to halt. If not press harder or panic/ 

You could try and record this all as different levels of BP if you really want to I guess - the Capabilities and Function do not really have the characteristics of processes. A dictionary defines process as"
"A series of actions or steps taken in order to achieve a particular end", "A systematic series of mechanize/chemical operations that are performed in order to produce something". So for something to be a process there is clearly implementation of series and sequence (which is may not exist for functions "An activity intended for/natural to a person/thing"). If I am buying a car I probably don't need Use Case (I may well not need Process models - Function will usually be enough).

FEAPO consensus definition of EA [and TOGAF doesn't help]

Federation of Enterprise Architecture Professional Organizations

Based on (http://www.itworldcanada.com/blog/the-great-debate-what-is-enterprise-architecture-resolved-in-a-new-paper/86616)

FEAPO find 80% of organizations do not successfully execute the business strategies they have. Poor strategy execution is the most significant management challenge facing large public and private organization.

EA claims to address these challenges, but there is little consensus on what EA is (e.g. what the term means, what the practitioners do, how its processes relate to delivery e.g. agile, where it should report to, etc).

FEAPO's paper “A Common Perspective on Enterprise Architecture” seems to say the following (slightly paraphrasing [e.g. to reduce obscurantism I have used "perspective" or "aspect" instead of "viewpoint", and removed some of the tautologies e.g. "change initiatives"]):

1. EA is the activities and artefacts for translating business strategy into an effective enterprise and includes creating and communicating, and refining the key requirements, principles and models describing the enterprise and enabling transformation.

2. EA's value includes articulating the strategic requirements of the enterprise including:

• models which present what all aspects of the enterprise should look like in future states, and how they support the business strategy;
• a roadmap of the initiatives required to reach those future states;
• the requirements, principles, standards and guidelines that should govern implementation

EA outcomes include:

• improving the effectiveness, efficiency, agility and structure of the enterprise;
• improving the ability of the enterprise to continuously innovate;
• rationalising, centralising, federating and improving the completeness and quality of: business processes, business information and business rules;
• aligning spending on initiatives so that they deliver the strategic intent.

EA commonly maintains:

• information describing the enterprise in different states (“target”, “future”, "intermediate/transitional) [actually there is no future state - there are only future states) 
• perspectives that span the enterprise (across various unit or functional boundaries)

EA practices should provide efficient, effective, consistent analysis, planning, design, and implementation of strategic needs.

It postulates that non-financial measure exist [which I think a bit silly, in public companies where the sole focus is on financial performance]. Strategic planning does not produce a directly measurable ROIs [which makes more sense].

Elsewhere today I saw  http://www.ebizq.net/blogs/ea_matters/2013/11/togaf-needs-a-public-roadmap.php

Someone called "Len" indicates that TOGAF is a follower not a leader e.g. "The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does" [which should be no news to anyone]. [TOGAF has long been captured by technology vendors and dragged down to be solution and engineering oriented]

Adrian Grigoriu says (correctly in my view that) that TOGAF  "moves too slowly in who knows what direction, while it becomes irrelevant. In the meantime, because of its clout, it hinders the development of other EA approaches." [i.e. TOGAF is more an impediment (emperor's new clothes) than anything else]

When will EAs learn traditional approach produce traditional results?

I keep seeing people advocating variations on the traditional approaches to EA that have not worked for a decade or two. Traditional approaches with result in the traditional results.

At best these approaches are often like communism - they sound sensible and if everyone did the right thing, in the right way for the right reasons - they might actually work - but that isn't the world we live in and they just don't really work.

Here are some things that don't work

• EA based on the religious adoption of frameworks (that have been around for decades with almost no examples of success). These frameworks are usually abstract high level methods that in academic sense may be correct but are so generalised that in practice they little more than common sense aphorisms. They may also be taxonomies that claim to be canonical despite the staggering changes in the nature, size, and form of the things they claim to organize. For example TOGAF reminds one of rat pie instructions (http://www.oocities.org/sunsetstrip/amphitheatre/8707/rats.html)
• EA that is a kind of software architecture or systems architecture (with its arcane notations and business alienating terminology). These initiatives are often rife with technical notations from various technical design discplines (data modelling, object modelling, process modelling etc.)
• EA modelling that produces lots of hand crafted pretty pictures and wall art. These things can, often with some difficulty be used to communicate a message, but on close inspection it becomes clear that they semioticaly and semantically inconsistent. They remind you of iconic-graphic art explaining myths or fables.
• EA done by some EA consultants (no the organisation itself). Consultant will tell you it can be done this way. NO it can't. EA can not even be done by EAs alone - it has to be done by the organization, it is an organizational activity.
• EA done for EAs as an abstract ivory activity i.e. it is not intimately connected to where the rubber hits the road. Solution architects treat it with bemusement. BCP planner marvel at its incompleteness. Its relationship to down stream executions (e.g. business requirements which in practice form one the key inputs to any execution) is at best unclear.

Enterprise Business Demand and Requirements Management - EPM, COBIT, TOGAF

In developing a requirements management approach for a large enterprise it is essential to understand that business requirements are NOT software requirements. The history of failure in transformation initiatives is based on mistaken, traditional approaches, that fail to recognize the distinction between approaches suited to enterprises, solutions and solution elements (i.e. SW engineering, and its associated requirements methods, which is oriented at solution elements). And on a orthogonal but related axis that business views of things and engineering views - are different views.

In terms of things like the Scaled Agile Framework -  http://scaledagileframework.com/- the issues that need to be addressed 1st and foremost are at the portfolio level an above. It also needs to be recognised that for enterprises software development is a necessary evil NOT a a goal.

In developing our approach to demand and requirements management we considered things from a governance perspective e.g. using COBIT as reference, and an EA/SA perspective using TOGAF as a perspective and developed an approach leveraging off enterprise portfolio management - as in reality requirements leverage off and result in changes in the enterprise portfolio.

What is EA and what is EPM

There is a lot of miscommunication about what EA/EPM is, should be, could be, should be.

I keep coming back things said in Royal of Academy of Engineering and British Computer Society report on ""The Challenges of Complex IT Projects" (ISBN 1-903496-15-2)" e.g.
-  "there is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management ..."
-  "a striking proportion of ... difficulties stem from people ... failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry..."
-  "...  problems relate to the people and processes but further in developments in methods and tools is required to support the design and delivery ..."

Re the 1st point above - a starting point would be understanding what we mean by the terms/roles/areas of activity (and using another complex, but very mature, design domain as a parallel) -  for what it is worth - this was my view in 2007 (and remains essentially the same):http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html. But to summarise some very broad classifications:

- Portfolio Management (EPM, Property Portfolio) - is not about design it is about economics and metrics (risk, cost, value, etc.).

- Planning (Town Planning, Strategic IT Planning) - is not about design either - it is about having view of the future at different points in time and mapping out, usually broadly, how to get make these views reality.

- Standards Management (Building Material Codes and Standards, Technology Standards Management, Patterns management, Principles definition) - is not about design of any specific solution/design its is about saying what we should build with and how we should assemble those elements. The economic drivers of standards management could come from portfolio management, but if guidelines are easily and accurately reflected in down stream processes then the proliferation of complexity and diversity will proceed unabated.


- Enterprise Architecture (City Design, Large Project Design e.g. Olympic Complex) - is about the design of enterprise (and encompasses many aspects of the above) and unlike its built environment counterpart the flow between what we want to do and with what technologies we do it is far more fluid (because the materials/technologies in the built environments change order of magnitude more slowly).

- Solution Architecture (Building Architecture) - is about design, but it is not really about detailed engineering or construction of the various modules, elements or systems that the building is created from (that is done by specialized sub-trades).

- Software Engineering (covers a multitude of sins - e.g. many Building trades - plumbing, interior design) and it is design.

- Systems engineering to achieve performance standards - "ilities" - is about design and relies heavily on patterns and best practice and calculations.

No one it their right mind would suggest that the same tooling/technology/modelling be used for all of the above:
- Property Portfolio
- Town Planning - maps might be useful
- Standards Management
- Enterprise Architecture - maps useful but insufficient
- Solution Architecture - maps referenced, some CAD capabilities required
- Software Engineering - many CAD trade specific design systems require
- Systems Engineering - as for Software engineering but different e.g. analysis of structure, heat etc.

So one gets an eco-system like this:

Enterprise Architecture - need for diagrams, better requirements, considering change over time

Simple statement of some of the issues. Identifies needs for:

• the need for diagrams to represent complex design and problems with current specification techniques (e.g. lack of semantic precision)
• over focus on technical requirements at the expense of real business requirements and outcomes
• analogies with city planning
• need to consider change over time
• need to model the future and do analysis 

http://www.youtube.com/watch?v=ToigBlcQhnc

If and when you can help people with improve demand and requirements management to support transformation

In deciding if one can help people improve how they approach demand and requirements management:

1. Do they recognise the need to base requirements on their business/technology plan/architecture - as this provides the only canonical reference point. If they don't then point them at the material that explains why and leave them for a year or two.
2. Do they recognise the current requirements in an architectural vacuum, document oriented, often software engineering lead, approaches to requirements have been failing, appallingly for a decade. It fails for everyone but the consultants and SW engineers. If they don't then point them at the material that explains why and leave them for a year or two.
3. Do they recognise that engineering  requirements, methods and modelling are oriented at wrong things for the wrong people. If they don't then point them at the material that explains why and leave them for a year or two.
4. Do they recognise that what is required are solutions where all stakeholders can access information in ways suited to the tasks they perform, that all demands and requirements need to reference a common view of the enterprise? That each project dealing with requirements, should as a by-product, of its elaboration improve that view of requirements? That is do they recognise:

• Requirements should be captured referencing the enterprise's architecture (as a building project references the town plan)
• Requirements captures should  help identify and remediate gaps in the enterprise's architecture (as a building project will identify gaps and errors in a town plan).
• Overlaps across projects will only be visible when the reference to a canonical source is in place (as one can see on a town plan if buildings will overlap)
• a common vocabulary of requirements affect on the architecture is needed (to avoid dozens terms which mean the same thing, or may not)
• documents and other specifications should be automatically generated (as reports on data, not narratives purporting to be data)
• common ways of rating things (based on data) should be in place - such as: value, risk, feasibility, cost, clarity, etc.
• we should be able to identify potentials impacts of a change in the business architecture on all projects 
• the criticality of all stakeholders have immediate direct access to requirements, in forms and at levels of detailed suited to their roles (diagrams, documents, visualizations; heatmap, roadmap, impact map; etc.)
• the need to link explicitly the requirements to putative solution elements (to support delivery management)

If you get here - you can explore with them issues associated the cultural changes in the organisation and look at solutions and methods that support decision making and knowledge accretion.

The bottom line is you can't help people who don't want to be helped - and the 1st they need to make (for themselves) is to recognise there is a problem and they need to do something. See the 12-step programme for treating addiction to failed ways of doing things.

Remember Planck's Principle (not his constant) - "A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it."

Enterprise Architecture - a term that could be abandoned

This (http://www.ebizq.net/blogs/ea_matters/2013/09/post.php) posits that we "cannot even agree on what architecture is". 

While I don't think this true in a broader sense, I do agree in the context of EA (and in fact IT).

I don't think it true that we not agree on what architecture is. Architecture is a fairly well defined discipline in the building industry. I trained as an Architect. It is fairly well understood what it means.

I do think it true that the IT industry has a poor understanding of the function EA. This is because the term is anachronistic, and does equate to the "Architect" in building (equating more to City/Town Planner). By anachronistic I mean it was coined in a very different era of IT - when there was typically only a single system, often a single language, etc - as if there was a single castle (not a city).  I would also suggest Solution Architect's - who do equate more closely to the role of the Architect in building - are not clear on their role. This is because many are by background SW engineers, they think SA is really just SW engineering. Like a carpenter (electrician, bricklayer etc.) thinking Architecture is about is about carpentry.

In the this context I would suggestion the description provided in the item is an example of the flaw i.e. Architecture is not systems per se, though systems are encompassed. We would be better to abandon the term EA - and instead of the:
-  E word say: "business", "product", "process", "system", "software", "services", "assets" etc.
-  A word say: "design", "planning", "asset management", "governance", etc.

If we were really smart we would look at mature industry i.e. building and use that as a reference model and relate our concept to that - so we would understand our equivalents (see http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html).

It reminds me of other anachronistic terms e.g. fraternize - which has little to do with being brotherly; presently - which has little to do with now; etc.

Technology Architects need to realize they not paid to be artists

Technology Architects need to realize they are not paid to be artists and people don't expect to pay to self actualize. A key aspect of their function is to communicate, and when there are many working together that means they should use a consistent and relevant set of concepts (objects, relationships, properties, etc.) and communicate those concepts in a consistent way (colours, layouts, shapes, text etc.)

Enterprise architects needs to take some leadership here. While it may be true that for many technology architects (some of whom are really software or systems designers - with a grandiose title) their main audience is themselves (who really reads their SAD tomes), and handful of developers (who can in a project context learn a specifically set of semiotics). Enterprise architects need to co-ordinate communication across an enterprise.

I originally created this to try and communicate the challenges I have in discussions with these people in around 2010/11. In it "Widget" is intended to refer to anything e.g. applications, functions, systems, etc. (http://www.xtranormal.com/watch/7867545/)

I created an updated version that uses the word "Things" instead (http://www.xtranormal.com/watch/13610352/modelling-things).

I kind of prefer the original.

Enterprise Portfolio Management vs Software development

There are solutions being advocated for enterprise architecture and EPM that come from a SW design heritage. They were often originally UML modelling tools and they have grown from there. I am often asked about where these things fit.

I trained an architect (buildings etc.) and worked with CAD and GIS systems for many years. In organizations with immature EA practices the EA is often lead by "architects" who are ex-developers, who have failed to make the conceptual transition to understand EMP. You will often find them using developer oriented tools to do enterprise portfolio management, enterprise architecture and governance.

This is akin to using a CAD system to do GIS (as people did do once). CAD can be made to work for mapping at a small scale; and some mapping systems can be made to work to record very large plant. But really city plans are not really just drawings (or dealt with best by design oriented solutions). They need to deal with the placement and relationships of all the assets in the city and the characteristics of those assets (e.g. characteristics of areas of land, or assets on that lead). They need to allow analysis of those assets and characteristics. This is best done using GIS/AMFM solutions. The city plans also relate to building and construction codes that specific materials and their valid usage (technology standards) and allowed patterns of construction (technology patterns).

CAD systems are best used for doing detailed design of specific elements and assets. Of course it should be remembered that many assets will be bought not built, or outsourced. It should also be recognised that difficult types of CAD system are oriented at different domains e.g. mechanical, electrical, architectural, etc.

In today's enterprises what you have were great developers, or infrastructure designers (analogous to builders, or the various trades' designers), who may or may not have made the transition to be "solution architects (analogous to architects), pretending to be EA's (analogous to town planners) or EPM (property managers).  These people are in their multitudes running around with their CAD systems (of different types: UML, ER, BPM etc.) building stuff - with no clear oversight of why things exist, how they relate, how things can be simplified, etc. and very little in the way of a picture of the long term value, maintenance etc. of the assets they are creating.

See: Copernican shift in EA or the ancient EA analogies with the built environment

Reference Models are meant to be referred to

I have seen many organizations adopt, and in some case pay money, for reference models - with no real idea of what a reference model is and how it should be used. Reference models should be referred to not just instantiated and bastardized.

For example an industry reference model may indicate a set of functions that are common to an industry (or a set of information objects an industry will usually need). The reference model should have within it the relationships between the reference models functions and the reference models information.

If a business relates its functional to the RM-Functions and its information model to the RM-Information that analysis if possible of inferred relationships and gaps.

If a business just copies the RM-Functions, RM-Information objects, etc. and makes its own hacked versions of those their business-models, information-models; abandoning in the process the ability to link their models to the Industry Reference models they lose the ability to "refer" the RMs and updated versions of them. They can no longer easily determine where they differ and why. They fundamentally don't understand what a "Reference" model is.

Why don't EA's want to change?

Max Planck said "A scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it. ". 

I think this can be generalized to "A better approach or more accurate way of seeing the world, does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it". 

Oh if only it were true what William Blake said "Truth can never be told so as to be understood and not be believed"

But in perhaps we need to look to George Orwell for the explanation in industries dominated by fashion, lead by marketeers "In a time of universal deceit - telling the truth is a revolutionary act". 

Matthew 7:6  also bears reading