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.