EA as a set of vectors.

This is kind of interesting: http://www.infoq.com/news/2011/07/ea-as-vectors.

I am sceptical of the need to introduce quantum physics into the equation. It immediately brings to mind Dawkins law of the conservation of difficulty: "Dawkins's Law of the Conservation of Difficulty states that obscurantism in an academic subject expands to fill the vacuum of its intrinsic simplicity. Theoretical physics is a genuinely difficult subject. Envious disciplines, ...conceal their lack of content behind billowing clouds of deliberate obscurity".

However I do think that it indicates some leading thinkers are starting to focus some key things I am focused on:

- complexity and the need to deal with it (http://ea-in-anz.blogspot.com/2007/11/need-to-manage-complexity-better-in.html)

- problems with the silo lense of a projects (http://ict-tech-and-industry.blogspot.com/2008/08/projects-are-artifical-constructs.html)

- organizations are reactionary (http://ea-in-anz.blogspot.com/2008/07/focus-on-ea-is-inversing-proportional.html)

What I am proposing are specific solutions and methods that address these issues and provide enterprises some key capabilities a way of:

- dealing with complexity and making behaviour less subject to natural reactionary influences (e.g. less subjects to the persuasive, but illogical, narrative of powerful individuals), by allowing concepts to be made explicit and related in what call the "democratization of transformation"

- providing a holistic view of transformations and a virtuous cycle of improving understanding e.g. by allowing all initiatives to be related to a view of the enteprise and feedback into that view - starting with all business cases and requirements being expressed in terms of a common shared view.

Enterprises do think in time frames. These timeframes may be referred to as states. They are not states in the sense that an object modeller thinks of the states of an object e.g. a switch "on" or "off". That are states in the sense of stages of progress in views of something at a point in time, recognising that a journy is in progress. I have said for a long time that the term "future state" with the definite article is illogical, there is not a single "future state" their are a continuum of states. This doesn't mean we shouldn't set targets for where we should be at points in time.

"... A project or whatever doesn’t change the organisation from ‘current state’ to ‘future state’: instead, it provides a vector that points towards a particular direction at a particular speed. The vector does sort-of imply a ‘future state’ at an arbitrarily-chosen future point in time, but that kind of frozen-time snapshot belies the dynamics of what’s actually going on. And vectors intersect: hence whilst a single vector may point to a ‘future state’, the interaction of all the vectors will inherently take the overall system someplace else."

[Many projects are influencing what things like look in at different points in time future]

"... The value of a “to-be” architecture is then primarily to help us understand the benefit being realized by the steps along the way. ..."

"... And EA needs to understand the complex interaction between many different changes. A typical enterprise is teeming with lots of different change initiatives, some of which may be formally constituted as "projects". ... these projects and other change initiatives interact (compose themselves) in usually unpredicted and possibly unpredictable ways. ...The ability of complex systems to preserve their identity and deep structure in the face of efforts to change them has been studied by many systems theorists..."

[Many projects are influencing things and we need to try and understand their net result and their interactions. We also need to recognise complex enterprise are intrinsically reactionary]

"... view modernization as a more holistic and multidimensional activity which plans and delivers a progressive transformation of the As-Is business through a series of maturity states on a number of (yes OK) vectors"

[We need a more holistic view]

What we can learn about Requirements from Engineering

This item (http://www.dataweek.co.za/news.aspx?pklnewsid=39316) focuses on engineering requirements and solution vs enterprise requirements and solutions.

Nevertheless some of the issues they deal just as relevant at a business or enterprise level, as they are hard to deal.

They are mainly hard to deal with as a result of misapplication of techniques that are well suited to engineering electronics (or software) but very poorly suited to architecting a business. These techniques are dragged into the enterprise requirements domain by technicians or consultants. It is as if we have allowed the languages and techniques of the plumber, or the electrican to be foisted on the town planner.

Extracts from the item below in italics with my comments

...focused on requirements and the proper management of requirements throughout the process. [yes, obviously critical. So it is pretty why a static document e.g. a requirements document won't do the job]

... requirements must be captured, reviewed and validated, managed and traced to design implementation and verification activities. .... a checklist of criteria against which you review the requirements .. a method to link requirements to the design implementation...

[Yes all necessary. At an enterprise of business level I refer to "Acceptance", "Acceptance criteria" as the process use to Verify results. We use this terms because it is business and contractually oriented term i.e. to distinguish from whatever testing/validation engineers (or suppliers, or sub-contractors) might seek to do.]

... Tracing requirements to design implementation and verification results

[made difficult by]

... requirements can be volatile [i.e change. Obviously they change]

... the mechanism to capture requirements is disconnected from the design environment [in a business context one needs to ask why. Really what they mean is that the requirements are disconnected from the engineer environment and there is no discrete design environment per se. That is why we focus on Solution Management and ensure the management of the solution discrete from the engineering of the elements of that solution. A lot of the complexity in business technologies results from failure to define and manage this boundary]

... often takes an expert to do any sort of ‘management’ of the requirements [in business context this is simply not viable because we need the business knowledge to define requirements. We must find a way they communicate and manage their needs]

... the implementation and verification of requirements occurs within a variety of environments and tools, each with their own language, format, process, location and experts [again in a business context this can not be case with acceptance of a solution by a business user]

... link requirements from the highest system level to the lowest-level implementations of hardware and software. [and what businesses need is to link requirements from the highest level of the business to the lowest level component that they pay for discretely. Things beneath this level are necessarily encapsulated be the bespoke of off the shelf]

... Requirements changes, and their downstream impact, are all highlighted ...

... Requirements validation checklists are both built-in and customisable

... Requirements traceability is automated and up-to-date with the design

[yes, yes and yes]

... After all, what company wants to produce a design that does not meet its requirements? What company wants to stand up in front of their customer and say “We have finished your design, but it does not do exactly what you want.”

[Or we have completed your expensive projects but they have not met the shareholder's or stakeholders requirements to produce value or outcomes]

Challenges with TOGAF

Some problems with TOGAF:

Process not a project - People tend to think of it a cyclic set of sequential steps (like a SDLC waterfall) rather than a continuous process with parallel contemporaneous steps (more like an agile approach to development). Iteration is an attempt to overcome the limitations of waterfall approaches and allow management gateways to be implemented; and static artefacts (documents) to be used as the means of communication. This is probably because it is overly oriented toward solutions architecture (and arcane languages like UML).

A generic approach not a specific way to do anything - It is a generic approach that doesn't say specifically what to do to solve any specific business problem, or deliver specific business value. That is not to say it isn't correct - it is to say it is hard to follow.

A method unimplementable without a solution - It is like teaching someone the principles of accounting and then asking to do the accounting for a large organization using Word and Visio to create the invoices and do the reporting.

Continuous change and dynamic architecture - Yes. Versioning is not the answer, the answer is that all people all access information and that artefacts are produced dynamically representing the current understanding.

Horses for courses

I see Methods and Tools recent poll mixed results for UML http://www.methodsandtools.com/dynpoll/oldpoll.php?UMLPoll2

I would suggest few doubt that UML (or UML like OO analysis) is useful. The key things are to determine when it most useful and when it is not particularly useful. It is strange for me to be writing in support of UML as I more usually pointing out that it does fit well in the domains I predominantly work on now e.g. strategy and strategic architecture.

That only 14% of people use UML on all projects makes sense (perhaps they all have complex OO projects), that 45% of people use it, or some of its techniques, on some projects makes ever more sense.

That 11% of people have abandoned it suggests to me that it has been misapplied. Way back when started reading what is now Methods and Tools it was called JOOP (Journal of Object-Oriented Programming) my focus was very much of OO analysis and development methods - but ever since those days I have seen SW developers (or ex developers) promote the use of UML where it is poor suited. They have their hammer (UML) and every problem is treated a nail. This has not helped UML.

The Agile method may be suitable for some projects but I don't see it as well suited to large complex initiatives, involving many parties and systems that need to be supported and extended over many years. This is because it fails to record or communicate complexity to the various stakeholders who need to participate over time i.e. who are not party to the face to face conversations, and don't read the code.

How to align analysis and strategy

I saw this "http://www.alinement.net/component/content/article/42"

My issue with this article is that it identifies a problem - and present no real answer.

This item raises two issues:
- Ambiguity in business strategy significantly impedes BA work and an uncertain strategy will delay getting clear answers to specific questions.
- An ability to make decisions where trade offs are required mean analysis and design impossible.
In both cases what is required is semantic precision.

BA could enhance their role if they applied semantic precision. Natural language and using word documents as the means of maintaining knowledge militates against this. The advice given covers some areas where precision is required - but gives no clues as to how to go about being precise.

Few would disagree that we need to be:
- Clear about the objectives and constraints (e.g. time-horizon)
- Understand the reasons for and importance of requirements (and know which are mandatory, which highly desirable etc.) i.e. record reasoning and priority
- Define the appetite for risk and innovation (e.g. how creative does the solution need to be) and in fact understand what is wrong with the current state (i.e. the implications of ‘doing nothing’)
- Identify and facilitate the resolution of conflicts between stakeholders - which must start by making such conflicts explicit e.g. A thinks XYZ is priority 3, B thinks XYZ is priority 7
- Concisely and specifically document your understanding of the strategies. [Using what semantics?]
- State sensitive assumptions. [And presumbaly relate them to something?]

The question is how can we: be clear, record reasoning and priority, make explicit relationships and record strategies explicitly.

The strategy should not be to put things into "words". It should be 1st to define a small canonical set of concepts (words, relationships) and use these with precision - and ontology if you like. This would allow us to eliminating synonomous terms, relate concepts explicitly etc. This allows us to be clear about what concepts are we dealing with and how do we relate concepts. How do we deal with priorities (and networks of prioritised items).

For example how do we rate importance e.g. is a requirement marginally critical to a high priority business goal more important (less important or equally important), than a requirement very critical to a medium or low priority business goal.

The strange idea of requirements before design, and design before construction

I continually dumb founded that other experienced and intelligent people thing that they leap into the use of a modelling tool to record concepts and analysis without being clear on the requirements or doing design. At present I am focused on modelling of enterprise - their operations, technologies and related transitions and initiatives. I always emplore people to:
1. gather the requirements (e.g. the questions they want the model to answer) BEFORE they start thinking of the design of the model
2. sketch out a rough design in some manual method (on paper, on a white board i.e. on anything but a computer modelling system) and get that design clear in their heads.
3. go about modelling.

But people presented with a modelling tool inevitably leap to 3. Some argue they implicitly know the needs (which I seldom buy) and some say they design best using computers (which I don't buy either).

I have written in other items in detail about why the way model something depends on the answers to be asked of the model. Which I won't recap on here.

AN ANALOGY FROM MY PAST
A CAD system, and in fact architectural drawing themselves, are models of a proposed or existing reality. They are way of communicating and analysing reality.

Once in my distant past after leaving Architecture school I specialised in CAD systems for architects. After a decade of using them (and at that stage I was as proficient as anyone in the world) with them them I became more and more convinced that in the vast majority of cases the use of these tools impairs the cognitive processes associated with conceptual design.

The conceptual design was better done on the back of an envelope, scratched in the sand of modelled roughly from wood and clay. I think this is for deep seated reasons to do with human cognitive processes and design. I think it has to do with issues of gestalt and post cognitive dissonance and the tendency for electronic tools to require greater precision (dimensional, semantic etc.) than should exist at the early stages of design - i.e. where it is better to leave some things loose, woolly, undefined/less defined.

This is not to say that they should not be used - but they should use to elaborate a design (not conceive one).

BPM findings based on AIIM report

BPM:

IS
- not a single software product or even as a suite of related software tools. It is management practice which might utilize a number of dedicated software mechanisms.
Involves
- an intrusive technology changing and re-shaping BP for higher performance.

MAY INVOLVE
- integrating applications, taking in electronic forms and edocuments, populating transactional databases and providing a single point of interface for users.
- process modelling and simulation, reusable process modules, and process monitoring and optimization.

DRIVERS AND RETURNS
- most important drivers are: cost savings from improving process throughput and reducing process steps; followed by Improving accuracy and repeatability
- accounts payable and accounts receivable processes showed the strongest success factors, followed by customer support cases, proposals and contracts, and claims processing.
- approx 1/2 of organisations achieved payback of their investment in BPM tools in 18 months, and 3/4 with 24 months.

LEADERSHIP
- 1/3 of the time BPM projects are lead Line of Business managers and in 1/3 IT take the lead.
- The strongest indicator for successful BPM processes is the presence of an existing process owner.

CHALLENGES
- integration with other systems is the biggest technical challenge

USAGE based on organisations surveyed
- 1/3 apply BPM to scanning all incoming mail.
- few currently extending managed processes across the supply chain, but many plans to.
- few are currently outsourcing BPM-enabled processes but many plan to
- 11% use BPM functions in SharePoint, but 3 times as many plan to.
- Spending on BPM SW should increase, and spending on BPM services should increase significantly.
- 1/3 look to buy their BPM tools from their existing ECM supplier, with 1/4 go for best-of-breed tools, and 1/4 preferring dedicated BPM suites.

Source
http://www.ebizq.net/blogs/bpm_insights/2009/12/-pdrtjs-settings-159850-post-1700-id.php