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."

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.

Technology Architects need to realize they not paid to be artists

Technology Architects need to realize they are not paid to be artists and people don't expect to pay to self actualize. A key aspect of their function is to communicate, and when there are many working together that means they should use a consistent and relevant set of concepts (objects, relationships, properties, etc.) and communicate those concepts in a consistent way (colours, layouts, shapes, text etc.)

Enterprise architects needs to take some leadership here. While it may be true that for many technology architects (some of whom are really software or systems designers - with a grandiose title) their main audience is themselves (who really reads their SAD tomes), and handful of developers (who can in a project context learn a specifically set of semiotics). Enterprise architects need to co-ordinate communication across an enterprise.

I originally created this to try and communicate the challenges I have in discussions with these people in around 2010/11. In it "Widget" is intended to refer to anything e.g. applications, functions, systems, etc. (http://www.xtranormal.com/watch/7867545/)

I created an updated version that uses the word "Things" instead (http://www.xtranormal.com/watch/13610352/modelling-things).

I kind of prefer the original.

Enterprise Portfolio Management vs Software development

There are solutions being advocated for enterprise architecture and EPM that come from a SW design heritage. They were often originally UML modelling tools and they have grown from there. I am often asked about where these things fit.

I trained an architect (buildings etc.) and worked with CAD and GIS systems for many years. In organizations with immature EA practices the EA is often lead by "architects" who are ex-developers, who have failed to make the conceptual transition to understand EMP. You will often find them using developer oriented tools to do enterprise portfolio management, enterprise architecture and governance.

This is akin to using a CAD system to do GIS (as people did do once). CAD can be made to work for mapping at a small scale; and some mapping systems can be made to work to record very large plant. But really city plans are not really just drawings (or dealt with best by design oriented solutions). They need to deal with the placement and relationships of all the assets in the city and the characteristics of those assets (e.g. characteristics of areas of land, or assets on that lead). They need to allow analysis of those assets and characteristics. This is best done using GIS/AMFM solutions. The city plans also relate to building and construction codes that specific materials and their valid usage (technology standards) and allowed patterns of construction (technology patterns).

CAD systems are best used for doing detailed design of specific elements and assets. Of course it should be remembered that many assets will be bought not built, or outsourced. It should also be recognised that difficult types of CAD system are oriented at different domains e.g. mechanical, electrical, architectural, etc.

In today's enterprises what you have were great developers, or infrastructure designers (analogous to builders, or the various trades' designers), who may or may not have made the transition to be "solution architects (analogous to architects), pretending to be EA's (analogous to town planners) or EPM (property managers).  These people are in their multitudes running around with their CAD systems (of different types: UML, ER, BPM etc.) building stuff - with no clear oversight of why things exist, how they relate, how things can be simplified, etc. and very little in the way of a picture of the long term value, maintenance etc. of the assets they are creating.

See: Copernican shift in EA or the ancient EA analogies with the built environment

Reference Models are meant to be referred to

I have seen many organizations adopt, and in some case pay money, for reference models - with no real idea of what a reference model is and how it should be used. Reference models should be referred to not just instantiated and bastardized.

For example an industry reference model may indicate a set of functions that are common to an industry (or a set of information objects an industry will usually need). The reference model should have within it the relationships between the reference models functions and the reference models information.

If a business relates its functional to the RM-Functions and its information model to the RM-Information that analysis if possible of inferred relationships and gaps.

If a business just copies the RM-Functions, RM-Information objects, etc. and makes its own hacked versions of those their business-models, information-models; abandoning in the process the ability to link their models to the Industry Reference models they lose the ability to "refer" the RMs and updated versions of them. They can no longer easily determine where they differ and why. They fundamentally don't understand what a "Reference" model is.

Why don't EA's want to change?

Max Planck said "A 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. ". 

I think this can be generalized to "A better approach or more accurate way of seeing the world, 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". 

Oh if only it were true what William Blake said "Truth can never be told so as to be understood and not be believed"

But in perhaps we need to look to George Orwell for the explanation in industries dominated by fashion, lead by marketeers "In a time of universal deceit - telling the truth is a revolutionary act". 

Matthew 7:6  also bears reading

Requirements of different kinds

Every project has different types of requirements it must comply with: business requirements (which are driven my the immediate imperatives of a set of business users, and relate to some aspect of the business's operation and performance); and strategic requirements (which are driven by broader, longer term goals). We could call the strategic requirements "architectural requirements" if we like – though this implies they have something to do with design per se (i.e. architecture). We can also consider other constraints e.g. project (cost/time etc.); technologies (materials availability, skills, to be used/not used), best practice (patterns, guidelines), existing assets (existing, and those to be created by other initiatives/activities)- which we could chose to consider under either the heading of business or strategic requirements. One can once again consider a parallel in a mature domain where we can see we have all of these.

In IT oriented solutions we have equivalents e.g.

A challenge in IT is firstly to get the different types of constraints understood. Secondary challenges are to get: 

• business requirements defined in business terms (in terms of business operations and outcomes) and,
•  designers/architects to realise they don't operate in a vacuum and that they need to consider and reference the constraints in their designs (ideally explicitly base on a canonical reference).