Brazen cynical lack of professional exemplified by people saying "what's in it for me"

It is far to often that I hear IT people employed on fat salaries by large enterprises say "what's in it for me". I sat in a meeting yesterday and heard this smug inane recant.

When pressed they will claim with smiling sophistry, that they mean "what helps me do a better job for my employer", but it is obvious to all, and from their behaviour, they mean precisely what they originally said.

I know of no profession, no priest, no architect, no engineer when asked to do their job in a proper and professional manner blithely chirps up with "what is in it for me".

What staggers me is not that people think this, many make think it, it is that people have the Trumpian temerity to say it out loud as if there is nothing wrong with it.

A decade ago the Royal of Academy of Engineering and British Computer Society identified in their report on issues with IT:

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

It is work reading - the report IT Challenges


Not a day goes by in enterprise IT without these point be exemplified.

My genuine interest is in working how to do things better and I can not believe the hours I have wasted with people who really do think "what's in it for me" is acceptable.

How some building architecture militates against EA work

The task of complex design is aided by two things:
1. a environment where what is being worked on can be visualised and remains in view...
2. a environment that allows thought

Modern open plan, hot seating arrangement neither. One can only wonder at the inanity of management who expect efficiency in this environments for complex design.

About 20 year ago I read a book - called Peopleware - http://hotcashew.com/2014/02/lessons-peopleware/


During single-minded work time, people are ideally in a state that psychologists call flow . It is a condition of deep, nearly meditative involvement, a gentle sense of euphoria when one is largely unaware of the passage of time. For anyone involved in engineering, design, development, writing or similar tasks, flow is a must. These are high-momentum tasks that only go well when you’re in flow. Unfortunately, it can’t be turned on like a switch, it takes a slow descent into the subject, 15 minutes of more of concentration before the state is locked in. Each time you’re interrupted, you require an additional immersion period to get back into flow. During this immersion, you’re not really doing work.

-- 

How can still be confusing solution and software architecture with enterprise architecture

I can't believe we are still having this discussion. Last time I met Mr Zachman, long long ago, I recall him saying the "the term 'Enterprise Architecture' doesn't have the word 'technology' in it"

I agree with Mr Kern - https://www.linkedin.com/pulse/persistant-misunderstanding-enterprise-architecture-matthew-kern . It is just sad he has to say it.

Cf. http://enterprisesto.blogspot.co.nz/2013/10/what-is-ea-and-what-is-epm.html

Architects like using Diagrams

When ever you talk to an architect (architect or technical) the first think most want to is draw something - usually some boxes with lines. These diagrams could be as simple as simple canvas views or as complex as detailed reference models or designs.

In an organisation with many people doing this and with many existing assets it is kind of useful if the boxes and lines relate to common concepts and assets. That is to say that if I draw a diagram which represents a new offering or service, for some markets, that relies on some offerings and assets (existing and new) - and someone else draws a similar diagram referencing some offerings and assets it is useful to know what is being referenced. So simple diagrams that don't link to each other or what exists (and all other diagrams) are not that helpful to enterprise (though they may service completely adequately the use of the author).  Further when I have a drawn a diagram in ad-hoc fashion that references things (i.e. laying things out in particular way), it is useful I can create a template without any further knowledge or skill for reuse by others.

So we believe the following characteristics are critical for such approaches to diagramming in an enterprise:

• portal based: to allow anyone in a distributed enterprise to access the data from anywhere, anytime on anything.
• simple for ad-hoc user: the reality is that the alternatives are a whiteboard or a simple drawing tool, and if a solution is much more difficult to use than this it won't be used, so it needs to be intuitive and easy to use.
• allow templates to be created on the fly: I need to be able to say this diagram will now be a template 
• allow data sets to be defined on the fly: I need to be able to say the data set in this diagram will be used elsewhere e.g. in other diagrams, in BI views etc.
• affordable for universal use:  because many people in an organisation need to be able to draw diagrams from time to time so 
• presenting data: allow the representation of data in repositories (which may in turn aggregate, collate that data from many other sources). This also helps ensure consistent semantics.
• control appearance based on data: allow the appearance of things to be changed based on properties of the underlying data and allow some common enterprise visual language to be used. 
• allow the underlying data to be updated: when in the course of drawing a diagram I see something wrong I need to be able to fix it.
• accessible to BI solutions: What architects don't usually draw are BI outputs, but the data in their diagrams need to be able to presented using these techniques

See also EA vs EPM

EAs need to communicate why decisions are made, by whom etc.if they want buy in

Understanding the rationale improves compliance

Enterprise Architects are often in a role of trying to get compliance with a set of decisions (or rules). If people can't see the rationale for the decisions, and it is not clear that their concerns and issues have even been considered, then they are unlikely to respect them (unless the penalty for not respecting them is severe).

The nature of any decision in a complex domain (from highest level strategies to the lowest level decision on  a technical or operational approach) is predicated on a set of goals, factors and beliefs. If we can as much as possible make the basis of the decision clear we can improve the chance of compliance or buy in.

Goals and principles

Any rule must be predicated on achieving some goal (otherwise it would have no purpose). Principles to some extent often reflect a class or kind of goals.

Patterns are decisions

Patterns also reflects sets of design decisions. All design involves trade offs. Explaining the thinking (goals/princioples, factors and beliefs, etc.) will assist in people understanding what patterns fit their circumstance.

The world changes

The other consideration is that we live in a changing world. Goals, facts and beliefs change. If we adopt a religious approach to following decisions or rules without being able to inspect their predicates we are unable to determine if a decision/rule that once made sense remains sensible.

If we record the key goals, factors and belief and how they relate to decisons/rules we can understand the impact of a change e.g. if a goal become more or less important, a factor changes etc.

It is for these reasons that in our solutions relating to managing quality (consistency, best practice, etc. including:reference models, decisions on reference models, patterns, principles etc.) that we seek to get the rationales recorded.

Silo behaviour in large organizations militates against agility

At present in large organizations the different functions are usually in silos that don't talk to each other, and don't really care about other. They seem to forget that often what they do is of little value unless it is related to things other do - but they operate in silos.

For example:

• the people who do process models are not the people who do capability maps (which the processes are presumably to enable), 
• different people again may do information models (to describe the information to be used by the processes and support organization's knowledge goals)
• another group manage the application portfolio (which is to support the processes and capabilities, the data etc.)
• another group are responsible for "business analysis" which should relate to processes, capabilities, information etc) 
• another group manage projects (which will affect changes to process, capabilities, applications etc.).

Each group focuses on optimizing how do things for their specialist audiences (who develop increasingly specialist and arcane needs), but the reality is that no matter how well each silo operates it is of no value unless well integrated into the whole. 

It is not that it is of a little less value, it is really of almost no value to the organization. So each silos attempt to excel only benefits the individuals involved, their CVs, their personal satisfaction, etc. 

There needs to a Maslovian hierarchy of needs for these areas - where down the bottom is - who well integrated is what I do with what others do. 

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.