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.

Leadership is required for management and governance

Management and governance functions can not reasonably be expected to be driven bottom up.

No designer wants a governing body telling them what the can and can't; should or shouldn't do. It is the nature of good designers to want the freedom to do what ever they think is best.

Many designers barely tolerate the client i.e. they would rather design in the absence of this and frequently consider the clients needs, aesthetics, predilections etc. an impediment to a good design. I recall a house I was once in that had paster moulded cherubims coming out of the wall and a range of those tasteless eclectic abominations that the client had demanded. The client was happy with the result but did comment - "we went through three architects, they just kept leaving".

Designers of course accept the need for a client. But you can't expect them to run seeking further sets of constraints on their creativity. Architects don't go looking for extra town planning and codes of practice to comply with.

Nor can you expect designers to seek to publish patterns and techniques that they have spent a decade mastering so everyone else can be as good as them.

In the realm of IT it staggers me that many IT organizations look to their solution design (architecture) function to define its approach.

It is critical that the CIO and IT executive team stand up and take responsibility for ensuring the best utilizing of   the existing IT porfolio; that the best extensions to that portfolio (from the organization's perspective); correct application of best practice (patterns, principles etc.); effective harvesting of best practice (patterns); etc.

Make good information available to everyone

I like what Jeanne Ross (Director and Principal Research Scientist at MIT’s Center for Information System Research) says as reported here: http://www.zdnet.com/blog/gardner/enterprise-architects-play-key-role-in-transformation-data-analytics-value-but-they-need-to-act-fast-say-open-group-speakers/4489

Coming from the siloed past in IT, companies are now moving to business service-driven processes across various resources ... But they need to recognize the forces around consumption of such services, not just the implementation.

Making good data management a priority, a “single source of truth” is also at the heart of making EA valuable,...Ensuring the quality of data and the speed of data refresh will help enterprise architects rise in performance appreciation more than just about anything else..."

“You don’t get good analytics with bad data,” ...“The secret to good EA is to put information in every person’s hands so they can use data better.” And that in turn will help transform the business and spur added innovation using IT systems and good architecture principles.

Most senior executives aren’t very good at combining business and technology strategies

Principles and patterns

I have looked at these "principles" for many years and it seems to me: firstly that they are effectively constraints (almost like goals, measures of success i.e. something to be achieved ideally) and that secondly they are often opposing constraints. So that what is required in design in an understand of the trade-offs. 


This turns out to be very complex if tackled from 1st principles so in mature disciplines the idea of patterns is used which effectively encapsulate a set of principles (and materials) to suggest how something can be achieved. The seminal work on patterns (Pattern Language) reflects a practical approach in another design discipline - which also has principles.


I am not convinced that principles in their raw form can effectively be consumed and applied. They are good things that theorists like to talk about but almost useless in practice.


To use an imperfect analogy - cars one could imagine a set of principles: agility - be flexible for many purposes, go off road; capability - be able to store lots of things and people; user appeal - appeal;  speed - be fast; ease of use - easy to operate, park etc.; good TCO - economical to run; cost effective - economical to buy; etc.


But these won't tell us what type of car we want to buy or build - let alone details of a specific model. What we 1st need to understand is the pattern.  


Do we want an SUV: agility - yes; - capability - yes; user appeal - no; speed - no; ease of use - no; good TCO - no; cost effective - no.

Do we want an small hatch - agility - partial; capability - no; user appeal - no; speed - no; ease of use - yes; good TCO - yes; cost effective - yes.

Do we want an sports car- agility - no; capability - no; user appeal - yes; speed - yes; ease of use - no; good TCO - no; cost effective - no.


Our principles have not changed - but our priorities have and the patterns SUV, Hatch, and Sport car reflect this.

This comment was originally made in response to this: http://www.ebizq.net/blogs/ea_matters/2011/11/enterprise-architecture-principles-lets-talk-about-them.php#c19997

Counter-reductionist approach to requirements and projects

I like what this man Dr. Leon Kappelman says "It is the bane of applications and data to be stovepiped and compartmentalized. But that remains the standard by which we train IT and business managers" (http://www.information-management.com/newsletters/data-architecture-quality-integration-UNT-Kappelman-10021830-1.html).

He came to EA the same way I came to EA ie.

"My original focus was software development and obviously the importance of getting the requirements right. Well, it turns out that to have the requirements right, you need what you are working on in the context of the whole because otherwise you might build a great system but it doesn't create value. It might be adding redundancy or be the 73rd system to connect 72 other systems. Even if those other 72 systems are part of stovepiped business units and are perfectly aligned with them and serve their needs, as a whole the enterprise is wasting a ton of money and a ton of resources and talent."

I think it great that he identifies the problems with the “reductionist” which I had put down to solipsism of many of the technical people I have met who are interested just in their little slice of reality - their jigsaw piece. The problems are not just with technologist, but with projects in large organizations, where most operate as if the project's by itself produces business value.

I think we need to look at solutions and methods to suppirt a counter-reductionist approach. That is why we have focused on a strategic holistic approach to demand and requirements management.

EA - leadership and discipline supporting a cultural shift

MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation - http://www.zdnet.com/blog/gardner/mits-ross-on-how-enterprise-architecture-and-it-more-than-ever-lead-to-business-transformation/4463

What I like about this is the clear identification of the:

• cultural shift that is required
• need for understanding through the enterprise (not just with individuals) and the identifying the limitations of the "hero" model
• need for discipline and the natural tension that needs to exist (Cf. the town planner vs the laisez faire property developer)
• difficulty of getting good adoption of and need for persistent coaching and a clear vision
• need to focus on pain points that the executive are focused on (not boiling the ocean)

Cultural shift

"... we’re learning about enterprise architecture is that there’s a cultural shift that takes place in an organization, ... and that cultural shift starts with abandoning a culture of heroes and accepting a culture of discipline."

Enterprise, not just individuals using an heroic approach

"...What companies traditionally did before they started thinking about what architecture would mean, is they relied on individuals to do what seemed best ...Nobody wants to get rid of the heroes ...What we’re trying to do is adopt a culture of discipline, where there are certain things that people throughout an enterprise understand are the way things need to be done, so that we actually can operate as an enterprise, not as individuals all trying to do the best thing based on our own experience."

Natural tension

"... the architect should be able to create a very constructive tension in the organization, and that’s the tension between individuality, innovation, local responsiveness, and the need for enterprise thinking, standardization, and discipline."

Focus on pain points

"... companies who were best at adopting architecture and implementing it effectively had cost pressures. What happens when you have cost pressures is that you’re forced to make tough decisions. ...If you have all the money in the world, you’re not forced to make tough decisions. "

"... The best architects are listening very hard to who is asking for what kind of capability. When they see real demand and real leadership around certain enterprise capabilities, they focus their attention on addressing those, in the context of what they realize will be a bigger picture over time. ...They can already see the unfolding bigger picture, but there’s no management commitment yet. So they stick to the capabilities that they are confident the organization will use. That’s the way they get the momentum to build. That is more art than science and it really distinguishes the most successful architects."

Getting adoption requires persistent coaching

While the following comments are not directed at EAMS solutions I think them apropos

"... You build something that’s phenomenally good and appropriate for the business and then you just assume, that if you give them a little training, they’ll use it well. "

" ...That’s actually been a remarkable struggle for organizations. ..."

" ...there aren’t very many companies that have come anywhere close to leveraging their platforms the way they might have imagined ..."

" ... It’s harder than we thought. It requires persistent coaching. It’s not about training, but persistent coaching. It requires enormous clarity of what the organization is trying to do, and organizations change fast. Clarity is a lot harder to achieve than we think it ought to be."

When will we learn that heroic individualism is not enough

In an presentation to EA many years ago I quoted a third party who had suggested some of the the goals were: containing costs and risks, be timely, being more adaptable and customizable and the challenges included managing complexity (which requires some discipline and semantic precision) and failing methods “Today, the most common model … is based on an approach that we call ‘heroic’ ”. Some of the suggestion made at the time were: context maps for cataloging assets and knowledge; clear methods for making decisions; patterns, business/industry reference models, default infrastructural templates or frameworks; and focusing on component topologies and interactions.

This source for this is not recent - it is an old IBM Systems Journal item in 1999 discussing architecture.

Summary

I have written elsewhere on strategies for dealing with complexity (the key being semantic precision), industry reference models and patterns (which encapsulate principles, preferred technologies, standard component topologies and interactions). This item from Ross is great in identifying some of keys to successful implementation: clear vision and persistent coaching, discipline, enterprise wide approach etc.