There are many ways of visualising data held in Troux. Troux provides OTB diagram generation -
- using Flash frameworks in the Troux Navigate Portal
- using Troux Architect fat client modelling tool
Here are some of the features we think people want: Features of Visualisations
There are other ways of visualising data held in Troux: SEMPRE Visualisation Framework
Conceptual views Common views producing models, documents, reports
Monday, April 27, 2015
Sunday, February 9, 2014
Round tripping and other IT fairy stories
IT should recognise that round tripping seldom takes places automatically in mature domains. Design are not normally round tripped. If the data passed in is changed those changes are usually dealt with by a specific process i.e.
- a cadastral function defines boundaries and other features of the land may be recorded e.g. trees, streams, walls etc.
- a town plan has a map showing plots of land which is used by Architect. Walls, foundations, services etc. may be placed relative to the boundaries. If the Architect changes something that was on the town plan i.e. the data passed to the architect - there is usually some process of notifying the owner of the town plan/map (so they know of the change- as it may affect others)
- an architect defines a walls to be built by a carpenter. The carpenter works out where the studs, braces etc. and nails will go (these details are not normally passed back). If the location of the wall varies from the plan for some reason then dealt with by a process of notifying the owner of the building plan (it isn't just feed back into the plan - because the implications are not known).
IT frequently asked about round-tripping. Which may be possible - but I suspect seldom makes sense because as one descends down from business and conceptual objectives through to implementation and technical details - it is very hard to know what makes sense to feed upwards.
- a cadastral function defines boundaries and other features of the land may be recorded e.g. trees, streams, walls etc.
- a town plan has a map showing plots of land which is used by Architect. Walls, foundations, services etc. may be placed relative to the boundaries. If the Architect changes something that was on the town plan i.e. the data passed to the architect - there is usually some process of notifying the owner of the town plan/map (so they know of the change- as it may affect others)
- an architect defines a walls to be built by a carpenter. The carpenter works out where the studs, braces etc. and nails will go (these details are not normally passed back). If the location of the wall varies from the plan for some reason then dealt with by a process of notifying the owner of the building plan (it isn't just feed back into the plan - because the implications are not known).
IT frequently asked about round-tripping. Which may be possible - but I suspect seldom makes sense because as one descends down from business and conceptual objectives through to implementation and technical details - it is very hard to know what makes sense to feed upwards.
Thursday, November 28, 2013
The Peter Principle and Enterprise Architecture
It seems to me that many Enterprise Architects have been promoted from technical and design roles they were excellent at to knowledge management roles and business transformation roles that are poor at. The poor at these roles because they lack both the skills and the inclination.
They make not even be aware of what Enterprise Architecture is really about - that is to say they may not realise:
- Enterprise Architecture is about the business - so an understanding of business products, services, capabilities, plans, goals, strategies etc. should be their initial focus (if you don't get those right the details don't matter)
- Enterprise Architecture is NOT about Architects - and can't be done by Enterprise Architects per se.
- Enterprise Architecture is about managing and applying knowledge about the enterprise across the enterprise i.e. it is an ongoing process
- most methods advocated for Enterprise Architecture haven't worked, don't work and won't work.
- Enterprise Architecture is not SW Engineering (or SW Architecture) - it is in essence not even design or architecture per se. The "A" word describes the knowledge NOT an activity.
They will struggle even more if they think
- Enterprise Architecture has worked well in the past, so they should keep doing that
- Their role is to design (i.e. to architect) not to establish a approaches and solutions which allow architectures to emerge, be recorded, be analysed by a disparate community
This combined with no concrete objective (i.e. business relevant bottom line influencing measures) means that they survive happily with their "emperor's new clothes" artefacts based on the lastest abstract framework, method, etc.
They will skill fully apply Dawkin's Law of the Conservation of Difficulty - by advocating new "frameworks" and terms e.g. "viewpoints" and referencing people to abstract academic discussions rather than just using simple terms, plane english, simple approaches and just get on with what is in fact quite a simple exercise - if approached with the right mind set and solutions.
- Peter Principles: see: http://en.wikipedia.org/wiki/Peter_Principle
- 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, which I shall not advertise, conceal their lack of content behind billowing clouds of deliberate obscurity.."
Wednesday, November 27, 2013
What is wrong with TOGAF in practice.
TOGAF is like a religion, so one has to be very careful about saying anything against it. But ...
There are no real facts to suggest it works in practice. Most TOGAF initiatives fail, and have failed for a decade, but everyone pretends else-wise and says the next version will be better.
TOGAF has hang overs from its origin, originators and vendor sponsors - most of whom want to treat EA as if it is a super solution architecture (or even SW Engineering approach) which it is not. So they suggest iterations - which make perfect sense so projects/SW - but are ill-suited to architecture and governance activities which are processes (i.e. continuous and incremental not cyclic and iterative). This is also to mistake EA for EA implementation (which is obviously a different thing entirely) just as using/applying knowledge management is a different thing from implementation a knowledge management solution/approach.
TOGAF places requirements at the centre (which makes sense) but provides almost no information on how they should be dealt with (or what in fact they are); etc. And I suspect in their hearts they mistake business for SW requirements like most of the industry.
But putting all this aside the real issue is that TOGAF is just too abstract to be useful. What it says is often true, but is so facile as not to be useful.
If one wanted to implement Accounting one could:
a) implement an accounting system and immediately have a way to generate invoices, track debtors, apply tax codes, and have many reporting options (as starting points). One could then extend and adapt the system to meet any unique or specific needs.
b) read tomes on the locally applicable accounting methodology and tax codes and create an accounting practice using a mix of word documents, spreadsheets, etc. and perhaps creates one's own database. Then would could try and develop charts, reports etc. The system might work well for an individual who understood it well and it would keep teams of book keepers (often employed as consultants or contractors busy).
c) read an abstract method that encompasses the principles of all accounting methods globally with a set of abstract high level steps and building blocks - expressed so as not to relate to any country, organisation, domain, sector or system. It would be full of abstract aphorisms and concepts most of which make sense at some level - but provide precious little practical and pragmatic advice on what to actually do tomorrow.
The same is true for EA. As architects love abstraction, anything to get away from the business and business value, they always seem to favour c). Which is why they gravitate to TOGAF.
The challenge for many with a) is that it demystifies EA and makes it a prosaic thing anyone can use without needing to read a foot of paper on abstractions, frameworks, taxonomies, reference models, etc. What architect will go for that?
There are no real facts to suggest it works in practice. Most TOGAF initiatives fail, and have failed for a decade, but everyone pretends else-wise and says the next version will be better.
TOGAF has hang overs from its origin, originators and vendor sponsors - most of whom want to treat EA as if it is a super solution architecture (or even SW Engineering approach) which it is not. So they suggest iterations - which make perfect sense so projects/SW - but are ill-suited to architecture and governance activities which are processes (i.e. continuous and incremental not cyclic and iterative). This is also to mistake EA for EA implementation (which is obviously a different thing entirely) just as using/applying knowledge management is a different thing from implementation a knowledge management solution/approach.
TOGAF places requirements at the centre (which makes sense) but provides almost no information on how they should be dealt with (or what in fact they are); etc. And I suspect in their hearts they mistake business for SW requirements like most of the industry.
But putting all this aside the real issue is that TOGAF is just too abstract to be useful. What it says is often true, but is so facile as not to be useful.
If one wanted to implement Accounting one could:
a) implement an accounting system and immediately have a way to generate invoices, track debtors, apply tax codes, and have many reporting options (as starting points). One could then extend and adapt the system to meet any unique or specific needs.
b) read tomes on the locally applicable accounting methodology and tax codes and create an accounting practice using a mix of word documents, spreadsheets, etc. and perhaps creates one's own database. Then would could try and develop charts, reports etc. The system might work well for an individual who understood it well and it would keep teams of book keepers (often employed as consultants or contractors busy).
c) read an abstract method that encompasses the principles of all accounting methods globally with a set of abstract high level steps and building blocks - expressed so as not to relate to any country, organisation, domain, sector or system. It would be full of abstract aphorisms and concepts most of which make sense at some level - but provide precious little practical and pragmatic advice on what to actually do tomorrow.
The same is true for EA. As architects love abstraction, anything to get away from the business and business value, they always seem to favour c). Which is why they gravitate to TOGAF.
The challenge for many with a) is that it demystifies EA and makes it a prosaic thing anyone can use without needing to read a foot of paper on abstractions, frameworks, taxonomies, reference models, etc. What architect will go for that?
Thursday, July 14, 2011
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]
Wednesday, July 6, 2011
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]
Wednesday, April 6, 2011
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.
Subscribe to:
Posts (Atom)
