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