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

Best practices - based on Gartner's ten best/worst

Netting out best practices I seem to end up with:
1. Ground your EA in business strategy and context - the engage the right business people, appoaches and information
2. Focus on the value to be delivered - and get business sponsorship on that basis (not religously following academic EA Art/Language/Frameworks oriented at other EAs)
3. Have a broad plan - which outlines a set of iterations, and maturity levels to be achieved
4. Communicate to the business your plan - the value being delivered
5. For each iteration have manage delivery - as you would a project and measure the delivery
6. Operationalize governance - helping people work across the organization: facilitating, guiding, collaborating and supporting downstream activities and spending
7. Have competent people – communicating, facilitating, planning, organizing, engaging (as well as some technical understanding)
8. Focus on where you heading - future states and where you want to get to.
9. Use solutions to enable what you are trying to achieve.

This is based on: http://www.infoq.com/news/2012/04/Best-Worst-EA-Practices (why some paraphrasing)
Ten best practices
1. Ground your EA in business strategy and context.
2. Execute a Communications Plan – to the business outlining the value of planned EA developments.
3. Scope, phase and iterate - pragmatically
4. Manage each iteration like a Project – deliverables, resourcing, 
5. Start with the Business Strategy and Obtain Business Sponsorship
6. Do the future state before the current state – focus on where you want to get to.
7. Operationalize governance - helping people work across the organization: facilitating, guiding, collaborating
8. Measure effectiveness of the EA program
9. Track maturity 
10. Have competent people – communicating, facilitating, planning, organizing, engaging (as well as some technical understanding)

Ten worst practices:
1. No link to Business Strategic Planning and Budget Process
2. Treat "Enterprise Architecture" as if it were "IT Architecture"  
4. Lack of Governance
5. Focusing on the Art/Language rather than Outcomes – business outcomes should drive the efforts
6. Focusing on EA Frameworks – 90% of enterprise architects use a mix of frameworks and don't use them as cookbooks 
7. "Ivory Tower" approach - focusing on art/langauge/frameworks in an academic way with an inner circle of EA experts
8. Do not communicate and feedback
9. Limiting the EA Team to IT Resources – you should engage with business people
10. Do not measure effectiveness

Also 
http://www.eweek.com/c/a/IT-Infrastructure/Enterprise-Architecture-Must-Become-Business-Driven-Gartner/


“Focusing on a standard EA framework doesn’t work,” 

“In the past, EA practitioners focused on deliverables that were useful to enterprise architects but not valuable to senior management and/or did not respond to a specific business or IT need.“ - see also
http://enterprisesto.blogspot.co.nz/2012/06/leadership-is-required-for-management.html


“...The value of EA is not in simply ‘doing EA,’ but rather in how it can help evolve the business ..." -  see also: http://ict-tech-and-industry.blogspot.co.nz/2009/01/12-step-program-for-enterprise.html


Five types of deliverables suggested

1. “... Measurable deliverables that address specific business outcomes and work with other business and IT disciplines such as business process management, program and portfolio management, business information, finance and human resources to leverage their efforts and move to value-driven EA.”
2. " ... Actionable deliverables, which drive change and must have a direct relationship to business outcomes and stakeholder requirements and present senior IT or business executives with a decision to be made or a specific action to be taken that moves the business toward a future state. "
3. " ... Diagnostic deliverables, which include models, requirements and analysis tools that are designed to enable IT and business leaders to understand the impact of different decisions made in response to business disruption or business opportunity. ..."
4. " ... Enabling deliverables are composed of information that is collected; they provide input to diagnostic deliverables that represent the business, people, processes, information and technology ..."
5. " ... Operational deliverables are the artifacts that EA practitioners use to help them define, communicate and run their EA program. ..."

High Performance EA; Some postulated business goals

High performance EA
and some other things  have seen recently (direct quotes from referenced sources in red). I like this (http://blogs.cio.com/enterprise-architecture/17249/build-high-performance-ea-practice). 

Lessons  - why-school EA has failed to deliver
 "has been too tactical, too technology-centric, or too disengaged from business priorities to have significant impact"
Alternatives

1. no EA programme - "business change is likely to occur in a siloed, uncoordinated fashion"
2. old fashioned EA programme - there will be "an arms-length relationship between IT and the business".
3. an improved EA programme - "high-performance EA ...where":

• "Business architects works with business thought leaders to distill strategies. Leveraging input from executives and business SMEs, the high-performing EA practice generates a target state of the business that achieves its strategic objectives, and a transformation road map that builds the business capabilities the enterprise needs."
• "Business and IT architects work collaboratively to set tech strategy. EA works with IT leaders to set a strategy that leverages both new tech innovations and existing capabilities that will enable the business to achieve the target state."
• "Architects govern portfolio decisions to enable the business architecture vision. Business architects monitor the project portfolio, while IT architects govern technology solutions, leveraging reference architectures to build the future state in alignment with strategic road maps."

Some business goals related to EA

This study make be interesting (http://www.marketwatch.com/story/study-analyzes-usage-scenarios-for-enterprise-architecture-management-2012-07-16). It does postulate some common business goals related to EA i.e. 

"The study identifies potential benefits for the business goals "economies of scale", "innovation potential", "synergy effects", "holistic process management", and "simpler production processes". 

EA politics

I think is an excellent item and identifies the challenge I see all the time - which I summarise as "we are too busy to have time to think or plan". http://www.ebizq.net/blogs/ea_matters/2012/07/enterprise-architecture-politics-and-their-roots.php

• Behaviour "... is tactical at best. Firefighting would better express the fact ..."
• But the discpline is meant to be "... strategic in nature ..."
• Some keys to success: "... plan integrally. ... have a clear, holistic plan in place ...", " ... deliver often, iteratively, on time and fit for purpose. ..."

The greatest irony in this is that most people recognise that EA requires cultural and process change. Further that these changes, which will involve many small changes to many people and processes, will take place in large organization over time. But if you ask them what their 3 year plan is for EA - or ever what their goals are for this year, next year and following - they struggle to suggest anything meaningful. They revert to some focus on a fashionable framework and some complex abstractions that have caught their attention.

The other things EA's must accept is that what they have been doing doesn't work for most of the enterprise. So they need to assess what they do: people, process, tools.