Thursday, September 19, 2013

Enterprise Architecture - need for diagrams, better requirements, considering change over time


Simple statement of some of the issues. Identifies needs for:

  • the need for diagrams to represent complex design and problems with current specification techniques (e.g. lack of semantic precision)
  • over focus on technical requirements at the expense of real business requirements and outcomes
  • analogies with city planning
  • need to consider change over time
  • need to model the future and do analysis 

http://www.youtube.com/watch?v=ToigBlcQhnc

Tuesday, September 17, 2013

If and when you can help people with improve demand and requirements management to support transformation

In deciding if one can help people improve how they approach demand and requirements management:
  1. Do they recognise the need to base requirements on their business/technology plan/architecture - as this provides the only canonical reference point. If they don't then point them at the material that explains why and leave them for a year or two.
  2. Do they recognise the current requirements in an architectural vacuum, document oriented, often software engineering lead, approaches to requirements have been failing, appallingly for a decade. It fails for everyone but the consultants and SW engineers. If they don't then point them at the material that explains why and leave them for a year or two.
  3. Do they recognise that engineering  requirements, methods and modelling are oriented at wrong things for the wrong people. If they don't then point them at the material that explains why and leave them for a year or two.
  4. Do they recognise that what is required are solutions where all stakeholders can access information in ways suited to the tasks they perform, that all demands and requirements need to reference a common view of the enterprise? That each project dealing with requirements, should as a by-product, of its elaboration improve that view of requirements? That is do they recognise:
    • Requirements should be captured referencing the enterprise's architecture (as a building project references the town plan)
    • Requirements captures should  help identify and remediate gaps in the enterprise's architecture (as a building project will identify gaps and errors in a town plan).
    • Overlaps across projects will only be visible when the reference to a canonical source is in place (as one can see on a town plan if buildings will overlap)
    • a common vocabulary of requirements affect on the architecture is needed (to avoid dozens terms which mean the same thing, or may not)
    • documents and other specifications should be automatically generated (as reports on data, not narratives purporting to be data)
    • common ways of rating things (based on data) should be in place - such as: value, risk, feasibility, cost, clarity, etc.
    • we should be able to identify potentials impacts of a change in the business architecture on all projects 
    • the criticality of all stakeholders have immediate direct access to requirements, in forms and at levels of detailed suited to their roles (diagrams, documents, visualizations; heatmap, roadmap, impact map; etc.)
    • the need to link explicitly the requirements to putative solution elements (to support delivery management)
If you get here - you can explore with them issues associated the cultural changes in the organisation and look at solutions and methods that support decision making and knowledge accretion.

The bottom line is you can't help people who don't want to be helped - and the 1st they need to make (for themselves) is to recognise there is a problem and they need to do something. See the 12-step programme for treating addiction to failed ways of doing things.

Remember Planck's Principle (not his constant) - "A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it."


Friday, September 13, 2013

Enterprise Architecture - a term that could be abandoned



This (http://www.ebizq.net/blogs/ea_matters/2013/09/post.php) posits that we "cannot even agree on what architecture is". 

While I don't think this true in a broader sense, I do agree in the context of EA (and in fact IT).

I don't think it true that we not agree on what architecture is. Architecture is a fairly well defined discipline in the building industry. I trained as an Architect. It is fairly well understood what it means.

I do think it true that the IT industry has a poor understanding of the function EA. This is because the term is anachronistic, and does equate to the "Architect" in building (equating more to City/Town Planner). By anachronistic I mean it was coined in a very different era of IT - when there was typically only a single system, often a single language, etc - as if there was a single castle (not a city).  I would also suggest Solution Architect's - who do equate more closely to the role of the Architect in building - are not clear on their role. This is because many are by background SW engineers, they think SA is really just SW engineering. Like a carpenter (electrician, bricklayer etc.) thinking Architecture is about is about carpentry.

In the this context I would suggestion the description provided in the item is an example of the flaw i.e. Architecture is not systems per se, though systems are encompassed. We would be better to abandon the term EA - and instead of the:
-  E word say: "business", "product", "process", "system", "software", "services", "assets" etc.
-  A word say: "design", "planning", "asset management", "governance", etc.

If we were really smart we would look at mature industry i.e. building and use that as a reference model and relate our concept to that - so we would understand our equivalents (see http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html).

It reminds me of other anachronistic terms e.g. fraternize - which has little to do with being brotherly; presently - which has little to do with now; etc.