Brazen cynical lack of professional exemplified by people saying "what's in it for me"

It is far to often that I hear IT people employed on fat salaries by large enterprises say "what's in it for me". I sat in a meeting yesterday and heard this smug inane recant.

When pressed they will claim with smiling sophistry, that they mean "what helps me do a better job for my employer", but it is obvious to all, and from their behaviour, they mean precisely what they originally said.

I know of no profession, no priest, no architect, no engineer when asked to do their job in a proper and professional manner blithely chirps up with "what is in it for me".

What staggers me is not that people think this, many make think it, it is that people have the Trumpian temerity to say it out loud as if there is nothing wrong with it.

A decade ago the Royal of Academy of Engineering and British Computer Society identified in their report on issues with IT:

• "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 ..."

It is work reading - the report IT Challenges


Not a day goes by in enterprise IT without these point be exemplified.

My genuine interest is in working how to do things better and I can not believe the hours I have wasted with people who really do think "what's in it for me" is acceptable.

How some building architecture militates against EA work

The task of complex design is aided by two things:
1. a environment where what is being worked on can be visualised and remains in view...
2. a environment that allows thought

Modern open plan, hot seating arrangement neither. One can only wonder at the inanity of management who expect efficiency in this environments for complex design.

About 20 year ago I read a book - called Peopleware - http://hotcashew.com/2014/02/lessons-peopleware/


During single-minded work time, people are ideally in a state that psychologists call flow . It is a condition of deep, nearly meditative involvement, a gentle sense of euphoria when one is largely unaware of the passage of time. For anyone involved in engineering, design, development, writing or similar tasks, flow is a must. These are high-momentum tasks that only go well when you’re in flow. Unfortunately, it can’t be turned on like a switch, it takes a slow descent into the subject, 15 minutes of more of concentration before the state is locked in. Each time you’re interrupted, you require an additional immersion period to get back into flow. During this immersion, you’re not really doing work.

-- 

How can still be confusing solution and software architecture with enterprise architecture

I can't believe we are still having this discussion. Last time I met Mr Zachman, long long ago, I recall him saying the "the term 'Enterprise Architecture' doesn't have the word 'technology' in it"

I agree with Mr Kern - https://www.linkedin.com/pulse/persistant-misunderstanding-enterprise-architecture-matthew-kern . It is just sad he has to say it.

Cf. http://enterprisesto.blogspot.co.nz/2013/10/what-is-ea-and-what-is-epm.html

Architects like using Diagrams

When ever you talk to an architect (architect or technical) the first think most want to is draw something - usually some boxes with lines. These diagrams could be as simple as simple canvas views or as complex as detailed reference models or designs.

In an organisation with many people doing this and with many existing assets it is kind of useful if the boxes and lines relate to common concepts and assets. That is to say that if I draw a diagram which represents a new offering or service, for some markets, that relies on some offerings and assets (existing and new) - and someone else draws a similar diagram referencing some offerings and assets it is useful to know what is being referenced. So simple diagrams that don't link to each other or what exists (and all other diagrams) are not that helpful to enterprise (though they may service completely adequately the use of the author).  Further when I have a drawn a diagram in ad-hoc fashion that references things (i.e. laying things out in particular way), it is useful I can create a template without any further knowledge or skill for reuse by others.

So we believe the following characteristics are critical for such approaches to diagramming in an enterprise:

• portal based: to allow anyone in a distributed enterprise to access the data from anywhere, anytime on anything.
• simple for ad-hoc user: the reality is that the alternatives are a whiteboard or a simple drawing tool, and if a solution is much more difficult to use than this it won't be used, so it needs to be intuitive and easy to use.
• allow templates to be created on the fly: I need to be able to say this diagram will now be a template 
• allow data sets to be defined on the fly: I need to be able to say the data set in this diagram will be used elsewhere e.g. in other diagrams, in BI views etc.
• affordable for universal use:  because many people in an organisation need to be able to draw diagrams from time to time so 
• presenting data: allow the representation of data in repositories (which may in turn aggregate, collate that data from many other sources). This also helps ensure consistent semantics.
• control appearance based on data: allow the appearance of things to be changed based on properties of the underlying data and allow some common enterprise visual language to be used. 
• allow the underlying data to be updated: when in the course of drawing a diagram I see something wrong I need to be able to fix it.
• accessible to BI solutions: What architects don't usually draw are BI outputs, but the data in their diagrams need to be able to presented using these techniques

See also EA vs EPM

EAs need to communicate why decisions are made, by whom etc.if they want buy in

Understanding the rationale improves compliance

Enterprise Architects are often in a role of trying to get compliance with a set of decisions (or rules). If people can't see the rationale for the decisions, and it is not clear that their concerns and issues have even been considered, then they are unlikely to respect them (unless the penalty for not respecting them is severe).

The nature of any decision in a complex domain (from highest level strategies to the lowest level decision on  a technical or operational approach) is predicated on a set of goals, factors and beliefs. If we can as much as possible make the basis of the decision clear we can improve the chance of compliance or buy in.

Goals and principles

Any rule must be predicated on achieving some goal (otherwise it would have no purpose). Principles to some extent often reflect a class or kind of goals.

Patterns are decisions

Patterns also reflects sets of design decisions. All design involves trade offs. Explaining the thinking (goals/princioples, factors and beliefs, etc.) will assist in people understanding what patterns fit their circumstance.

The world changes

The other consideration is that we live in a changing world. Goals, facts and beliefs change. If we adopt a religious approach to following decisions or rules without being able to inspect their predicates we are unable to determine if a decision/rule that once made sense remains sensible.

If we record the key goals, factors and belief and how they relate to decisons/rules we can understand the impact of a change e.g. if a goal become more or less important, a factor changes etc.

It is for these reasons that in our solutions relating to managing quality (consistency, best practice, etc. including:reference models, decisions on reference models, patterns, principles etc.) that we seek to get the rationales recorded.

Silo behaviour in large organizations militates against agility

At present in large organizations the different functions are usually in silos that don't talk to each other, and don't really care about other. They seem to forget that often what they do is of little value unless it is related to things other do - but they operate in silos.

For example:

• the people who do process models are not the people who do capability maps (which the processes are presumably to enable), 
• different people again may do information models (to describe the information to be used by the processes and support organization's knowledge goals)
• another group manage the application portfolio (which is to support the processes and capabilities, the data etc.)
• another group are responsible for "business analysis" which should relate to processes, capabilities, information etc) 
• another group manage projects (which will affect changes to process, capabilities, applications etc.).

Each group focuses on optimizing how do things for their specialist audiences (who develop increasingly specialist and arcane needs), but the reality is that no matter how well each silo operates it is of no value unless well integrated into the whole. 

It is not that it is of a little less value, it is really of almost no value to the organization. So each silos attempt to excel only benefits the individuals involved, their CVs, their personal satisfaction, etc. 

There needs to a Maslovian hierarchy of needs for these areas - where down the bottom is - who well integrated is what I do with what others do. 

Lightweight Portal based Visual Modelling using Troux

Lightweight Portal based Visual Modelling using Troux

We have developed a simple framework using Troux APIs and a graph path based approached to data to support simple visual modelling. This allows data in a Troux system to be presented to any user using essentially any device (e.g. mobile, tablet, Mac, PC etc.).

We have Troux an excellent solution for aggregating, analyse and present data in many ways. 

Our focus over the last decade has been on creating Troux based solutions.  In doing this we have found ways to unlock more value from data held in Troux, provide users additional ways of interacting with that data.

Our approach ensures that common data is used for all forms of presentation i.e. models, reports, charts and visualisations. This means that set of documents used in project concept and delivery are always consistent. 

Any path through the graph of related objects can be defined and presented without any need for coding (i.e. no XML configurations). Paths can be used to generate: models, reports, analytics, digarams.

There are many BI tools that allow data to presented, charted etc. (and all can be used to access data in Troux). Most adopt a tabular approach to the representation of the data (which is limiting when n-dimensional relationships need to be visualized).

Our frameworks focus predominantly on allowing information to be understood in context by enabling various diagrams or models to be to generated or defined. These diagrams may be: timelines; flow charts; cluster maps; graphs; etc.

Diagrams and visualisation can be configured by users and saved as templates for re-use.They can be presented in stand alone portals or via Troux portals. 

The visualisation framework is device agnostic and oriented at HTML5 browsers. 

Archimate in Troux

Using Archimate for Architectural Design in the Troux Portal and Troux Modelling client.

When designing for an organisation and as part of team it is useful to record and communicate why the design is as it is. We can record through the design process, as and when we see fit, how the solution relates to: requirements, decisions, features, standards, patterns, reference models, etc.

The technical and business architecture of an organisation provide a logical reference point for new solutions. It is particularly important to be able to anchor proposed changes (e.g, new solution elements) back to these when several initiatives are operating in parallel - so all expected changes can be seen and related. We can also relate the design tp the existing assets and items managed in portfolios.

We can analyse and track development of the solution.

EA and F1 - share at least one thing in common

I follow F1. I saw this comment today

"One of the keys to solving a problem is admitting you have one and then working as a group of people to understand it"

http://www.espn.co.uk/f1/story/_/id/13453746/the-key-solving-problem-admitting-one-rob-smedley

How I wish all the EA's and IT Executives would admit that they have problems that need to be solved. These problems don't impinge on most of the individuals happiness or ability to earn a living - but they dramatically reduce the cost and value effectiveness of large organisations. The duplication and inefficiencies please all the vendor community - who can sell more products and services than should ever be required, and the only real losers are the shareholders.

How we use EA to support the path from strategy to execution

In previous items we have discussed the problems with the gap between strategy and execution. We will now have a quick look at the problem and solution.

The problem is largely that the information is tied up in documents associated with a silo view of activities.

To make matters worse this set of documents takes a lot of work to create and includes things that are highly connected. So firstly when done manually it is extremely difficult to do well, very tedious to try and analysis (e.g. or completeness etc.) and soul destroying to try and maintain. This usually means it is poorly done. It also looks a lot of work - where the size of each ellipse below is an indication of effort

However by having the information in a common shared repository we can manage all the information failing easily, produce all the documents, and we actually do real analysis. When we look at each document we realise that there is a very overlap,

So we can substantially reduce the effort required i.e.

And we ensure integrity, we can reuse data from other sources explicitly and we do the analysis that is really needed

To provide other adhoc ways of understanding relationships we can use our SoA extensions to make the information paths available via standard BI tools, or via graph databases so that connections can be examined.

Requirements management needs to be done better - no kidding Sherlock

PMI Pulse of the Profession - on Requirements Management - https://www.youtube.com/watch?v=dSKbnNjrB1Q&feature=youtu.be . The good news is that the PMI doesn't - like most discussing requirements - orient everything around SW requirements management. And they clearly state there is a problem:

• 1 in 3 projects unsuccessful
• Poor requirements management is a major cause of project failure
• There is shortage of research on how to approach requirements management.

PMI defines Requirements Management as:

• Planning; Monitoring; Analyzing; Communication and Controlling Requirements
• a continuous process throughout a project

PMI says are Business Analysis:

• to be good an business analysis you need to be good at managing requirements
• it involves determining/identifying problems/needs; identifying viable solutions to meet the needs; managimg requirements to meet business/project objectives

PMI says re skills:

• the gap is not in technical skills
• you need to:
• interpret, align and articulate requirements related to the strategies [e.g. Goals, Strategies in EA]
• deal with ambiguity [which I suggest starts with identifying it - hence our unanimity score]
• communicate to many stakeholder i.e. not just developers [which I suggest is ill-served by the technician oriented artifacts, or loose narrative documents, typically produced  today]

Processes: 87% say improvement are required
Competencies: the need for competencies is recognised, but they just do it. Some areas include:

• ensuring solutions meet business objects [you would think it would be a good place to start with links to the goals, measures, KPIs etc. held in EA]
• identifying current and future states [which are also recorded in an EA]
• quantifying effort for requirements work [e.g. see our effort to elaborate properties]

http://www.federaltimes.com/story/government/management/blog/2015/06/25/managing-federal-acquisition-procurement/29266775/ - said on a related items:
- improving systems acquisition starts with improving requirements definition during program planning

Different languages and models for different purposes

Organisations, and individuals, operate in certain ways and the assets owned and used (we could choose to call these things their business architecture and their technology architecture). They need to manage and maintain their various assets to minimise e.g. cost, risk, etc. To manage these portfolios of things effectively they need to know what they are and if there are many of them be able to analyse them effectively.

They also have demands to change and make things better (i.e. transform and optimise). These demands necessarily relate to how they operate (i.e. changes to how they operate) and own (i.e. changes to what they own and use).

When an initiative(s) (e.g. a project) is put in place these demands are expressed as requirements and for a period a abstract view of future assets is described in designs and the elements of solutions (and how they relate). These requirements and designs are transitory, and specifically the level of detail they go to are transitory. They need to be able to relate to existing assets and ways of operating so the exact affect of desire change is clear.

When the initiative(s) are complete these requirements and solutions effectively cease to exist in the transition form used in the transition. At the end of the initiative and what remains are way things are done and the assets owned and used.

This sounds facile, why does this matter?

 It matters because we need to understand that we need to be able to manage:
a) the business and technology architecture
b) be able to define requirements and designs in the context of the business and technology architectures.
c) that we may used different models and languages for describing things e.g. we may use a different language, terms and concepts when we design a building vs when we own, used and operate a building.

I use the analogy of a building above because the average person is more familiar with a building and because therefore less easily mislead (as Dawkins's law of obscurantism is rife in IT). The reality is that designers need design languages and details to perform transitions e.g. Archimate is really a design language i.e. it is not oriented at the management of large sets of assets or holding comprehensive views of how business operate i.e. the business or technology architecture - but it needs to be to relate to these. Just as an architect needs to be able to relate his designs to the level held in the town plan and the property managers portfolio view - but his design views are not town plans - and different languages and models may be used.

Further - to summarise what I said here (http://enterprisesto.blogspot.com/2013/10/what-is-ea-and-what-is-epm.html)

Royal of Academy of Engineering and British Computer Society identified:

• "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 ..."

No one it their right mind would suggest that the same tooling, modelling and language for:

• Portfolio Management - is not about design (it is about economics).
• 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 - is not about design of any specific solution it is about saying what we should build with and how we should assemble
• Enterprise Architecture - is about the design of enterprise and has fluid relationships to the extant, but it is not about design solutions or engineering.
• Solution Architecture - is about design, though not really about detailed engineering or construction and need to apply languages like Archimate.
• Software Engineering and  Systems engineering - are about design and need to apply languages like UML.

See also http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html

Inferring purpose from artefact

I am often presented with an artefact that is has been created at some stage to address some problem. Inferring the purpose of the artefact can be difficult. What is amazing is that often the people creating artefacts have only vaguest idea of its purpose e.g. for whom, to do what, when, why etc.

It is a bit like someone showing you Stone Henge and expecting you to know its function is to tell the time.

And you are meant to work out they want to tell time.

Or being shown an ancient Pesian bowl and expecting to know they want to tell time

Or being presented with a grand a complication and being expected to know its function is similar to the above.

And you are meant to work out that they want a chime on the quarter hour.

In all cases they may really want something else entirely e.g. they may want a ceremonial assembly point, a lovely ceramic or a beautiful items of jewellery. The real point is that it is very difficult to infer purpose from an entity.

So you need to try and look as clearly as you can at what you want to achieve, rather than assuming what is wanted is a replacement for a current artefact.

http://enterprisesto.blogspot.com/2013/08/technology-architects-need-to-realize.html
http://enterprisesto.blogspot.com/2010/03/artifacts-vs-business-results.html

PMO Best Practices have never been effective enough for large enterprise transformation

I recently saw this: PMO Best Practices Are No Longer Good Enough. I had high hopes, but it identifies some issues - but fails to identify the real issue or the real solutions.

"... study after study concludes that investments in traditional PPM fail to deliver the
anticipated results ",

".. companies who are failing to realize the planned business value from project portfolios are facing three main problem areas – Annual Planning, Project Success Rates and Budget Utilization."

Failure to be clear about exactly what projects are doing - gaps, overlap, conflicts - as things change over time is the real issue. So yes "annual" vs continious is an issue and "success rate" are a problem - but more accurately tracking how quickly money is going down the drain, or identifying more money that can poured drain-wards isn't the answer

"... annual planning ...the business case for each investment often includes unreliable estimates. ... Unless those decisions are revisited throughout the year  ..."

This hints at the need for agile and continuous planning - but fails to recognise the need for agile managements and consider what information is really needed for continuous planning and management. As projects proceed they proceed from relatively vague understandings to very explicit undestanding - the real question are how is this knowledge captured and used.

"- ... Reliance on inadequate software tools is often the reason companies fail to successfully integrate investment planning and controls into the overall PPM lifecycle. Excel ... disconnected, difficult to govern and prone to hidden input errors; ERP ... great for finance teams not for PPM teams; Project Management Tools – strong at execution-oriented project and resource management capabilities ... "

Yes, but the issues lie above all of these. The issue in defining the details of scope and impact. The PPM tools/teams fail because the paradigm is flawed.

"... one thing is certain ... the days of “set it and forget it” are clearly over."

If only people got that it would be a start.

"... enterprise-focused PMO ... continuously evaluating the portfolio throughout the year.."

This will fail if PPM people continue to treat projects as black boxes and have no real ability to see with and across them to the details of the demands they address; what they deliver; and how they affect the business. They do this because PPM/PMO practice is based on a construction industry model which is a bad fit to business transfomation.

Dynamic planning requires dynamic understanding; and relies on dynamic management.

The issue isn't how to better ensure money is spent. The issue is how to better ensure that the set of projects as a whole produce the business outcome desire. This needs to start with an understanding that:
- Projects are artificial constructs managed in ways unsuited to enterprise transformation (see http://ict-tech-and-industry.blogspot.com/2008/08/projects-are-artifical-constructs.html)
- Classical project management fails in enterprise transformation - http://enterprisesto.blogspot.com/2014/01/why-classical-project-management-fails.html
- Complex transformation requires better ways to manage complexity - http://ea-in-anz.blogspot.com/2007/11/need-to-manage-complexity-better-in.html

Fortunately using a combination of a set of disciplines Semantic Precision has developed solutions that address the real issues.The approach involved a confluence of methods from: project and portfolio management; solution design management; requirements management; business architecture; enterprise architecture.

Plans and Strategies and the weakest link

Plans and Strategies are only really useful if they executed to produce the intended outcomes

To support strategic transformation and optimization three things are required:

1. Strategies and Plans: that can be demonstrated to be: based on facts (or explicitly stated testable beliefs) and produce the business outcomes desired if effectively and coherently executed.

2. Coherent orchestrated execution: so that the set of changes taking place within the various silos of activity are orchestrated as a set so that gaps, overlaps and conflicts are identified and resolved.

3. Agile and adaptive: that is the ability to adapt as changes occur to the facts, the beliefs or other circumstances. Often as a result of discovery during the execution activities themselves.

An issue with how things are usually done at present in business and IT transformation is that there is an ugly document layer that exists between what are typically two precisely modelled (i.e. sets of explicitly related concepts) layers. 

In this layer documents like: Project Definitions (Charters, SoWs etc.), Requirements Documents, Solution Design Documents (SAD, etc.), DR/BCP Plans are produced manually. This is time consuming, often obscures root cause analysis, and the artefacts themselves are seldom suited to most the audiences that are presented to (because most are only interested in a small subset of the information contained within them) and can't easily be maintained (or verified).

They are not explicitly connected to the layer above and provide no hooks for explicitly linking to the layer below. They provide scope for fictional narratives that executives, business stakeholder, et al may be persuaded to believe by the silver tongued.

We offer solutions that allow the middle layer to also be modelled (i.e. treated as data). The documents become reports. As they are reports it is easy to produce subsets specifically tailored to different audiences.  The contents of the documents (goals, requirements, solutions, milestones) are explicity related to each other and to the concepts above. Then they can be analysed (e.g. impact, overlap, cost, complexity, risk etc.) and the data managed (i.e. as change occurs over time). This allows agile approaches to be adopted while maintaining the integrity, coherence of the information and allowing the impact of changes (from bottom or top) to be understood in context.

Improving solution architecture by reducing the need for archaeology and being clear on requirements

I want to start with a simple analogy to avoid the scope for erudite excuses I hear so often from practitioners in IT. The reality is with new classes of solutions a very small change by each party can produce a dramatically different outcome.


Building - something we all know and understand
When a change is required to a building (or any complex technology) there are 4 things to consider when we are doing the high level design (e.g. the level of design done by architect):

1. how things should be built. For a build the building codes and regulations which indicate what things such as: technologies (products, materials) can be used for what purposes and in what way (patterns, best practice, standards, etc.) and; various other constraints re how the new building should relate to other existing, or future, elements in the environment (how it should connect, that it should not obstruct etc.)
2. what exists - For a build what existing buildings, infrastructures, common services, etc. exist (in just enough detail to know how they will be impacted, which is typically a lot less detail than is required to construct them i.e. we don't need to know where every nail or bolt is placed or necessarily where every detailed element exists or why).
3. what the requirements are. For the new building. what products and capabilities it should enable, what it should enable to be done (e.g. functions and processes it should support), what it should store, who should be able to use it (roles, positions, types of people), what characteristics it should have (secure, efficient, safe, etc.), budgets and key dates etc.
4. what will be delivered. For a building. a high design can be created that determines what is to delivered (built or bought) and how. It doesn't need to determine the placement of every building element - just sufficient to be clear what is to be delivered, how it relates to what exists, what requirements it meets (for the client) and that it will code with key codes (for the town planner). Most of detailed engineering designs necessary for constructions are done at follow stages by specialised engineers, designers and trades.

With buildings.
Town planning function aims to ensure:   a) how things should be built is clear
   b) what exists is know - so archaeological for new projects is minimised.
   c) what is built is recorded - so future archaeology is not required.
Architects aim to convey   d) what they understand the requirements to be
   e) what is to be delivered (for the client)
   f) how what is to be delivered meets the requirements
   g) how what is to be delivered relates to what exists
   h) that what is to be delivered is compliant with standards and codes.

Fortunately with building few town planners were once carpenters, who became architectures and then became town planners - and each level is relatively clear on its responsibilities, methods and tools.

IT - something we all know and understand doesn't deliver well.

When we look at changes in IT systems or businesses themselves we need to know the same things.

1. how things should be built e.g. what: technologies can be used for what purposes and in what way (patterns, reference architectures); other constraints re how the new elements should relate to other existing, or future, elements
2. what exists e.g. existing infrastructures or common services exist (in just enough detail to know how they will be impacted, which is typically a lot less detail than is required to construct them - i.e. we don't need to know where every nail or bolt is placed or necessarily where every detailed element exists or why).
3. what the requirements are e.g. products and capabilities enabled, functions and procesess supported, information stores, users (roles, positions), characteristics it should have (secure, efficient, safe, etc.), budgets and key dates, etc.
4. what will be delivered - a high design that shows is to delivered (built or bought) and how. It doesn't need to determine the details of every element - just sufficient to be clear what is to be delivered, how it relates to what exists, what requirements it meets, and that it will code with key codes. Most of detailed engineering designs necessary for constructions are done at follow stages by specialised engineers, designers and implementation specialists.

With IT.
Enterprise Architecture aims to ensure:   a) how things should be built is clear
   b) what exists is know - so archaeological for new projects is minimised.
   c) what is built is recorded - so future archaeology is not required.
Solution Architecture aims to convey  d) what they understand the requirements to be
  e) what is to be delivered (for the client)
  f) how what is to be delivered meets the requirements
  g) how what is to be delivered relates to what exists

  h) that what is to be delivered is compliant with standards and codes.

Unfortunately with IT many of enterprise architects where once are software engineers, who became solutions designers then became enterprise architects - and each level is not very clear on its responsibilities, methods and tools.

To complicate things further in a complex enterprise there are many initiatives operating in parallel and what is required to ensure all the changes fit together is a canonical view (common to all) or the things the requirements relate to: products, capabilities, functions, information, roles, positions etc.  So steps d & e need to allow all to understand overlaps and possible conflicts as early as possible.

How it can be done better With modern EA/EPM solutions the basis is provided for recording:
  a) how things should be built - standards and patterns
  b) what exists - so archaeological for new projects is minimised.
  c) what is actually built - so future archaeology is not required.
  d) what is requirements -

       by all projects and a specific project (explicitly related to a canonical view of the enterprise)
  e) what is to be delivered (solution architecture) can be clearly seen as a set of elements. 

      by all projects and a specific project (explicitly related to current assets and future assets).
  f) how requirements map to solution elements
  g) how what is to be delivered relates to what exists
  h) how what is to be delivered is compliant with standards and codes.

One can see from this that critical to improving how solution architecture is done - and minimising the need for archaeological efforts in this work is improving the recording of a to h. It requires a holistic view that sits above several streams of activity that are frequently siloed. Traditionally: EA has been strong on a, b but relatively weak on c. Solution Architecture has been weak on: d, e & f; Requirements teams have failed to relate their requirements to either a canonical of the business or its assets.

A very small change by each party can produce a dramatically different outcome.

Six keys to EA success

I recently read the six hereries for EA (www,eight2late.wordpress.com/2014/10/08/six-heresies-for-enterprise-architecture/). My thoughts follow

Distinguish between planning and design - The "self-referential" problems of EA extend past the frameworks to the practice and practitioners. This is because most of the have a background in engineering rather than planning (or architecture for that matter). By in large engineers create designs for engineers i.e. design practice to an extent is intrinsically self-referential. Plans are created for a broader audience.

Only consumption of a plan leads to value - The reason EA "rarely leads to anything of genuine business value" - is because too attention is paid to how the information can be consumed, acted on, etc - and the failure to realises the artefacts are not where the value lies.

Accretional rather than agile - What is required is an accretional approach. That is to say an approach where knowledge accrets. This is incremental, but has a different ethos to agile as applied in SW engineering i.e. where knowledge is transactional, transitory and related to a specific individual or outcome.

Virtuous feedback cycles - Planning assumptions and decision need constant testing and refinement. EA at present is too much like riding a bike, in a business city, with your eyes closed. You know where you want to get to and think you want know the direction. You close your eyes and take off. What you need to do is constantly assess knew information and adjust. The only way to get knew information is to apply the information you have, and this way have it tested and corrected. (see: www.enterprisesto.blogspot.com/2010/05/virtuous-circles-of-strategy.html)

Problem finding rather than problem solving - is great advice, but it is challenge for many who have a legacy as engineers or designers and secretly yearn to return to the comforting and satisfying realm of design i.e. solving problems.

Understand the social implications - is good advice, because the most of the impediments to EA are organisation and structural. (see www.ea-in-anz.blogspot.com/2008/07/focus-on-ea-is-inversing-proportional.html)

Demand and Requirements Management for Business Transformation

Demand and Requirements Management for Business Transformation

• the information relating to things in light blue stuff, at the top, are basically recorded in business architectures and asset portfolios solutions (i.e. they are canonical enterprise wide source)
• most of the money is spent on the green stuff - with the hope that it affects positively the light blue stuff
• sadly there is usually a disconnect between the light blue green 
• what purports to be the connections are created by lots of "consultants", "business analysts", etc. who create a plethora of persuasive, convenient, documents and presentations (essentially disconnected from the facts). 
• this disconnect militates against the real world value of business architectures and asset portfolios (which is why they are often rightly seen as ivory tower or academic exercises).
• that is to say that strangely in in most organisatons there is no source of record (canonical, complete or connected) for the darker blue boxes? 
• for most business the orange stuff is a necessary evil yet
• the approach to requirements is driven from engineer needs in the bottom right hand corner (on essentially a waterfall model)
• in an agile approach, which the only thing that can work, the information flows both ways
• (which is why the blue arrows go both ways i.e. as you define requirements in the context of existing views of capabilities and systems (i.e. business operational procedures, business assets etc.)
• you will discover things that are missing or need to be updated - which is good. That is because when you data you find issues with it and you improve it (this is what makes it non-ivory tower). 
• If you don't use the data in the business architectures and asset portfolios to actually make the changes happen who really cares about it - other than a few planners or startegists (when in reality it needs to be at the heart of business transformation)

BTM Decision Support - Agile Solutions

BTM Decision support solution — requirements 

Agility is key and there is a need to iterate rapidly through questions, answers ("art of the possible") and refinement cycles. 

Support the 4 common scenarios (see agile decision making for BTM ):

1. BTM tool experts to use tools to give the answers. In BTM these questions will arise often from many different people. They need to be answered quickly (an hour) with little effort (5-10 mins work)
2. End users experts need to get good enough answers for themselves (without recourse to an BTM tool expert). Of questions arising perhaps 20% will require this. Solutions need to be able put in place quickly (within an hour) with little effort (30 mins work)
3. Non-expert end users may want simple portal solutions with on-line analytics. Of questions arising perhaps 10% will require this. Solutons need to be put in place fairly quickly (a day or so) and with relatively little work (a few hours).
4. Non-expert end users may want simple task specific tablet/phone applications. Of questions arising perhaps 5% will require this. Solutions need to be put in place moderately quickly (a week or so) and with only moderate effort (a few days)

In all cases:

• the exact path through the labyrinth of data may be different for every question (and in some cases changes to the data model may be required on the fly). 
• the data may be presented in many different ways (report, diagram, chart, an interactive graphic etc.)
• the data may be captured and aggregated (from systems, people, models etc.) and it may be mechanism may be needed by which this data can be validated, maintained, trigger reviews, interrogated. etc.
• data access rules need to be applied to constrain who can see and change what.
• the solution used on a early scenarios provides a prototype for the solution to the next scenario

Our approach - we build our solutions on the world's best BTM/EPM platform and extend that so that:

1. BTM tool experts give the answers: we use dynamic reporting (which defined paths through the data); dynamic model templates; dynamic visualizations to support this.
2. End users experts get answers for themselves: we place the dynamic reports/analytics in a user accessible information portal to support this. 
3. Non-expert end users may want simple portal solutions with on-line analytics: we use sing a mix of  reporting/visualizations tools (using the data paths defined in early steps); dynamic portal configurations (navigators, layouts, workflows, etc.).
4. Non-expert end users may want simple task specific tablet/phone applications: we do this using a simple framework that re-uses the paths defined in earlier steps and some common extendable display templates.

Usually the data is reasonable well defined in the 1st two scenarios and the latter two scenarios are principally focused on supporting better interactions with the data and provider clearer insights.

Why many fixed OTB solutions fail:

• they make it too hard to change the data model
• they make it too hard to change the specific path through the data
• they don't provide interfaces for preferred device mix (PC, tablet, phone)

Why many flexible solutions fail

• they don't provide the full mix of output types (report, chart, diagram, interactive)
• they don't provide access control
• they don't provide mechanism for data aggregation, maintenance and integration

Agile Decision Making for Business Transformation Management

BTM method are immature and evolving

The fact is that BTM remains today as much an art as it is a science and consequently the methods used to support it are still evolving and maturing. 

Agility is key

People often have known unknowns and unknown unknowns i.e. things that, until they know more, they don't know they need to know, but don't know.

They will say things like "I we need to achieve this and I need to know more about that. But I don't know exactly what I want, but if you show me something I will be able to tell you if that is what I want, or if it is a bit different". 

This is why the "art of the possible" is important and the process to support decision making (and many other things) needs to be agile.

People need to rapidly iterate, through trial and error, until what is needed emerges. In fact the process may even be serendipitous. 

The real world isn't perfect but it is the one we live in


In the real world many ad-hoc questions arise and need to be answered in minutes (or within an hour). If the  stakeholder gets frustrated and can't get answers based on facts in these timeframes there is risk they will just guess (or go to someone who can make up an answer). These questions may only be only partially thought through, specific questions may never recur, and may change rapidly and iteratively as answers are provided.

Learning is about questions that lead to questions

You can see this even with a small child is trying to understand something. They ask question, which leads to another question and another and another. This is the process of learning i.e. intelligence requires iteration and agility.

Out of the box solutions provide a starting point - not an end point

Out of the box solutions for BTM decision support can only for the foreseeable future provide a starting point. They can't encapsulate definitive present best practice because best practice is inchoate and changing quickly as the industry as whole learns (unlike in relatively mature disciplines e.g. accounting, architecture, personnel management, etc.)

OTB solutions provide an idea of the "art of the possible" - but it is critical that they not seen as the way things must be done i.e. cast in stone. 

As it is inevitable that the questions asked will evolve, it follows that the data required (to answer the questions) must evolve, and the ways in which information is presented (and captured) will evolve. It is enabling this evolution which is critical and it must start with the data (if one things of a model, it is the metamodel).

Four BTM Decision support scenarios

1. Expert answer specific questions for specific users - Ad Hoc questions, needing quick answers, arise all the time. They may be the wrong questions (they may never be asked again). They need to be answered quickly and people will come to an expert is necessary to get an answer e.g. a specific report, number, chart, diagram etc. In answering these question it may be necessary to analyse or present data that is currently not recorded (so data model/metamodel changes are needed).

2. Expert user can get answers themselves - a small percentage of questions that arise will want to be asked and answered fairly often. People will want to be able produce the answer themselves e.g. a specific report, number, chart, diagram etc. It may require some expertise, but it doesn't require an expert.

A small percentage of questions from 1/2 will be of use to many users often (users with no specific expertise or knowledge).
3. Expert solution with generic tools - In some cases generic ad-hoc analytical tools, dashboards etc. may be able to be used to create answers
4. Expert Customised solution - In other cases highly customised and optimised user interfaces and analytics may be required e.g. for tablet, phone and watch interactions (with voice activited interfaces, continuous data collection etc.)

Let us take a non-BTM related every day example - how is my heart health

1. Expert answer specific questions  - I go to an expert to get my blood pressure checked, my blood tested etc. These tests may lead to others depending on what the answer are. In the following I just focus on one path (blood pressure)
2. Expert user can get answers - I want to monitor my blood pressure daily and track it
3. Expert solution with Generic tools - I can dump my blood pressure results into a spreadsheet and chart/analyse them

4. Expert customised solution - I have phone based application that monitors and records by blood pressure, sends alerts, and analyses the results (and compares with my diary, my diet record) presenting results on my phone or tablet - when I ask for them

BTM Decision support solutions.

They need to support all 4 scenarios and allow rapid evolution from one stage to the next ideally reusing information and solution elements from earlier stages.

1. Expert answer specific questions - solution needs 5-10 mins work with hour turn around

2. Expert user can get answers - solution needs 10-30 mins work and 1-2 hour turn around

3. Expert solution with Generic - solution needs less than an hours work and 1-2 days turn around 

4. Expert customised solution - solution needs a 4-24 hours work and 5-10 days turnaround (and results in an asset)