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.

A Copernican shift in Enterprise Architecture

This (Copernican shift) discusses a shift of centricity- for EA - from techno-centric to business-centric. I think it identifies some good points (see quotes extracted in italic below).

"... EA is becoming a thing that companies do, not a team they have"

We need to focus on how the enterprise gathers, manages and utilises the knowledge.

" ... the focus or central outcome is not technology success; it’s business success. ..."

We need to see how initiatives are driven by the business architecture and realise that ALL requirements (demand) must be driven by the business plan and architecture. Their are no technical requirements.

" ...This has profound implications for the skills and techniques that EAs need for the future. ..."

Items that discuss this further: EA solipsists ; I will be you CRMist ; EA can't be done by Enterprise Architects.

We need EA's to stop thinking their are going to engage the business with UML, ER diagrams, and other technical arcana (see UML no good for EA). We need EA who are articulate and natural communicators, collaborative and including (rather than doing pictures and models for their own or other EA's edification). See Communicating in languages the business understands

"... Integration takes on a broader context that includes people integration, process integration, and traditional technology integration. ..."

This is why in a taxomomy for EA we need to recognise as communications as key aspect of any EA "framework". Old "frameworks" (i.e. with rows and columns) - had columns for things like: what (knowledge, information, data etc.), how (function, process etc.), but lacked a natural column for communication - which ultimately drives the need for all interfaces (with people, with systems).

"... most successful firms will be “architecting their businesses for success …"
"… already seeing firms eschew the term “EA” as being to laden with techno-baggage. …"

Way back in 2007 - the need to use different terms was discussed here: Business and IT Transformation.

"Why Bad Things Happen"

"Why Bad Things Happen To Good Organisations: Part 1" - Jonathon Kendall is a very interesting.

Based on a study of public sector projects:
- only 44% of spend on capital projects is inefficient, with 31% completely lost
- only 13% of programs met more than 65% of targeted objectives. 
- only 59% of $100m+ programs longer than 5 years were delivered; 60% of those delivered were de-scoped or fragmented into other programs, and 22% were not delivered at all – none were delivered as per the original specification.
- 87% of IT programs go beyond schedule and budget, with an average overrun of 52%.
- 99% of all +$100m/5 years projects were significantly de-scoped, re-dimensioned or re-focused
- 2.25% is the average return of Corporate Service programs (they have worst return but made up over half of all capital projects undertaken.

They identify these factors embedding inefficiency:
- Lack of measurable, outcome-oriented performance metrics and reviews.
- Actual deliverables are not measured against promised or projected deliverables.
- Deliverables are not clearly articulated, defined or documented. 
- Gross over-estimation of program benefits compounded by gross underestimation of capital costs and risks. 
- Zero incentive for improved delivery performance. 

They recommend:
- Outsource Delivery Management
- Outsource Commoditised Services.
- Divest Commoditised IT Services, Invest In Specialised IT Services.
- Adjusted Benefits & Costs (to be realistic)
- Reduce Program Delivery Intervals. 
- Re-orient All Program Deliverables To Service Outcomes. "All capital works programs deliverables should be intimately equated with policy, legal, regulatory or directed outcomes."

A better approach to Requirements management - where the Requirements are directly expressed in terms of: policies, outcomes, KPIs and the capabilities and behaviour of the organization is in practice critical to many of the recommendations.  It allows you define in a common way the business requirements to be met by all outsourcing (delivery, commoditised services); clearly define specialised services (based on the specialised aspects of the business architecture)

Strategic Requirements management

Semantic precision has a brand new solution to this requirements management challenge based on an approach to business requirements, that leverages off a business architecture framework and is built on a business transformation management platform. See: www.semanticprecision.com

I think this item is excellent "Why is IT Project Failure Always an Option" http://java.sys-con.com/node/2007687 - extracts below

If the requirements in a single project are incorrect the outcome from that project is unlikely to be correct. But even if the requirements in a project are correct if the requirements across the set of projects that transform the enterprise are not correct (consistent, coherent etc. as a set) the net business transfromation result of all the projects across the enterprise is unlikely to be achieved.

I like the item below it makes the case that:

- project failure rates are high and unnecessary

- if you are not dealing with better approaches to requirements you're part of the problem

- a strategic view of requirements involves a direct connection between customer needs, IT spend, and strategic initiatives.

- maturity models are requirements

- an organization should be able to understands the strategic value of every project and be able to make daily decisions based on those values.

Extracts from the source below

"You [would] think that we'd be tired of the horrifying rates of failure, and the crushing consequences of those

failures ...

But if you are not spending more time understanding your customers - and developing tightly scoped

requirements to make great software to meet their real needs, not some imagined "needs mash-up" cobbled

together by the squeakiest wheels in your organization - you're part of the problem, and you're

accepting failure as an ever-present option.

It's time to stop the madness,... waste, ...cost overruns inpart from "inadequate requirements

management. ...

Most IT executives are familiar with the data on project risks, including overages and failure to meet

business needs. The risk described by Bent Flyvbjerg and Alexander Budzierin the September Harvard Business Review is that one out of six IT projects incurs "a cost overrun of 200%, on average, and a schedule overrun of almost 70% ...

It's time to get smarter ... and one way to do this it to take a strategic view of

requirements. A strategic view of requirements is not merely concerned with improving requirements or

improving projects; it incorporates a direct connection between customer needs, IT spend, and strategic

initiatives. It's requirements for grown-ups, and it involves maturing requirements.

The maturity model isn't just for app dev - it's for requirements as well. While most organizations

follow an ad hoc methodology for portfolio management and controlling project scope, a "requirements

mature" organization will find that all of IT understands the strategic value of every project (which

means that IT is aligned with internal AND external customers) and can make daily decisions based on

those values.

So, just what might this maturity process look like? It might look like a Requirements Center of Excellence. Here's one model for the increasing stages of maturity:

Stage 0: Ad Hoc. There is no requirements maturity. Requirements are created ad hoc, project scope is

based on "squeaky wheel"direction. ...

Stage 1: Individual. Although individual efforts may align with business strategy, there is no

consistent measurement of business return.

Stage 2: Team. Teams now share an understanding of business objectives; some individuals may share an

awareness of strategy. While individual projects may be measured for return, there is no organization-

wide validation of project return yet.

Stage 3: Business Unit. There is strong portfolio management across multiple teams. Teams and finance

consistently define and evaluate the project return across the portfolio. More than one business unit

may be at this level of maturity.

Stage 4: Organization. Throughout the organization, there is strong portfolio management based on

organizational strategy. The scope of projects is aligned with the strategy, and the entire portfolio is

regularly analyzed for business return.

... By making requirements strategic and by incorporating business strategy into requirements, not only will requirements mature faster, but those more mature requirements processes will lead to consistent business benefits.Which means great customer experiences, which come from great software.

EA Challenges - based on EA Excellence winners

This looks at some common challenges identified in: http://m.infoworld.com/d/enterprise-architecture/the-2011-enterprise-architecture-awards-173372?page=0,0

My summary of common challenges:

• building strong collaboration with business owners and IT to enable change scenarios to be explored – so reports and visualizations (suited to the various audiences) directly generated from the portal are key.
• adopting approaches – so senior management commitment was required to make the necessary process, role and cultural changes.
• unifying the architects: into a single, cohesive community using a common repository
• data quality and management - enabling any authorized user to update information, and as they go about their usual work, without need for training or modelling. So you can avoid collection, and survey exercises or bottlenecks through a modelling function/tool.

General

To be effective change agents, enterprise architects must possess a deep understanding of business process, and grasp both the potential and the practical limits of new technology solutions. Despite their crucial role and unique combination of skills, enterprise architects seldom get the recognition they deserve.

Bayer Healthcare

The biggest challenge was data input and management. In the past, data had been collected using surveys sent to various regions, which were difficult to reconcile and keep current.

Of particular importance was building strong collaboration tools, so business owners and IT could more easily share and discuss change scenarios. To facilitate this, reports and visualizations can be generated directly from the portal.

Singapore Ministry of Education
Because EA is a relatively new discipline, significant senior management commitment was required to make the necessary process, role and cultural changes.

USAA
The most difficult challenge has been helping the organization, particularly its business partners, to recognize the value of the approach. "Few organizations are ready to accept a unified architecture. It's a long road to educate the players and it needs to be done through grassroots efforts, finding champions and showing success through pilot projects that deliver value."

Another challenge has been unifying the architects themselves into a single, cohesive community and creating a metamodel and deliverables that all disciplines can agree to and benefit from. USAA is building a common repository, which will have joint ownership across disciplines and its own governance team made up of representatives from the architecture community.

EA Excellence Awards

I am often asked about examples of best practice. The following is an extract from: http://m.infoworld.com/d/enterprise-architecture/the-2011-enterprise-architecture-awards-173372?page=0,0 . Any comments I have made are in [ ...]

My summary

Each organization will take different path (based on their issues and priorities) - but some common themes emerge e.g.

• single road map: bringing together people, process, technology, information
• different perspectives: business, technology, and financial
• knowledge bridge between business operations and IT: supporting collaboration between enable enterprise transformation.
• online portal available to all: IT and business managers across the enterprise
• all architectural disciplines represented: business architecture, information architecture, application architecture, integration architecture, infrastructure architecture, change management, organizational design, etc.
• promoting standardization, simplication and management: applications, technologies, services, portfolios, transformation programmes
• visualizations is key: heatmaps, roadmaps, capability maps etc.
• scope is broad: business (business goals, capabilities), application and integration (application, SOA, interfaces, platforms/products), information (master data management, BI/data warehousen), infrastructure (data center, private cloud, provisioning).

We also note that leading adopters are looking at how to define their projects (requirements and solution elements) in the context provided by a holistic view of the enterprise.

Details follow

EA serves two main purposes: to provide a framework for collaboration between business and IT and to offer a pivot point for transformational change.

General

Each took a different path … [This is very important to realise. That is that each organization's approach to adoption may vary i.e. they may start solving the jigsaw puzzle from a different starting point – knowing that all pieces are there for a complete solution. Sadly some people just on piece of the puzzle and end up create a set of silos – and then repeat that pattern by create a different set of silos – without ever grasping that what is need eventually is a holistic view that runs across the top of all the business transformation areas]

American Express
... undergoing a major transformation. ...complexity of new product and service delivery channels, as well as the need for greater agility and shorter time to market ...

EA practice was charged with helping the company deliver a consistent, global, integrated customer experience based on converged services that run on a common application platform.

The EA practice has [delivers] reference architectures and road maps that promote standardized application architectures, facilitate innovation, and enable rapid product development.

In partnership with portfolio architects, the EA practice manages application architecture across multiple business solution delivery teams and develops business-aligned IT strategies. Each strategy contains a road map of initiatives that translates to measureable action and IT commitments to the business.

Road mapping is a core planning competency for architecture, engineering, service, and operations. It supports such business and IT goals as service management, portfolio simplification, prioritization, and IT-business alignment. Using a common tool, a consistent lifecycle management standard, and a standardized architecture governance process, three types of road maps are created: Technology road map; Reference architecture road map; Utility/capability road map

... business solution delivery teams to bring products and services to market faster by reducing infrastructure procurement and provisioning

... reference architectures [result] in fewer service outages, increased standardization of infrastructure, improved mean time to repair, and a dramatic decrease in support costs.

… extending its road map coverage to encompass: the rationalization of business capabilities and the maturing of SOA. ....

Bayer Healthcare

... history of mergers and acquisitions,

… launched its EA Management program with the creation of a global, Web-based Standards Management Platform ...

… is designed to act as a "knowledge bridge" between business operations and IT. ...

... Application Portfolio Portal [and] all related processes.

… online portal is available to all IT and business managers across the company. [many EA and plans team focus on a narrow audience – creating a silo of use]. Users can log in at any time to find an application and its related process data. The repository builds in application lifecycle management and proposals for specific activities, such as migration, integration, toleration, and elimination.

… includes assessments from business, technology, and financial perspectives and identifies application gaps, overlaps, and improvement opportunities. Applications are inventoried and registered against key metrics, and data integrity is maintained through an ongoing data stewardship program. Of particular importance was the need to build in strong collaboration tools, so business owners and IT could more easily share and discuss change scenarios. To facilitate this, reports and visualizations can be generated directly from the portal...

First Data
... a provider of transaction-processing solutions with more than $10.4 billion in revenue and 24,500 employees in 35 countries...

... EA function has created a framework for strategic technology programs to coordinate technology adoption and development in a manner that maximizes value. ..Through them, First Data will transform three technology layers: application (SOA, platform rationalization), information (master data management, BI, data warehouse consolidation), and infrastructure (data center consolidation, internal private cloud, provisioning automation).

EA is intertwined with nearly every aspect of [the] business. Its ability to drive product transformation is critical; this project will rationalize and consolidate product offerings, driving efficiency, simplicity, cost effectiveness, and agility.

… effective collaboration with development and vendor partners to ensure the benefits of emerging technologies ... This includes leveraging internal private clouds with provisioning automation, integrating real-time communication services (IM, videoconferencing), deploying consumer technologies (iPads), managing 120TB of enterprise data migrating to a consolidated warehouse.

USAA

… provides a full range of financial services including banking, insurance, retirement planning, investment services...

… membership has expanded significantly, leading to significant change in business models

... formed a cross-discipline, cross-organization team responsible for enabling the business to change processes, methods, and structure to align with broader member needs and newly available technologies.

... a customer-centric approach solely focused on meeting the needs of its members. It provides a single road map, bringing together people, process, technology, and information, rather than stand-alone process design and IT roadmaps. The approach represents all architectural disciplines, including business architecture, information architecture, IT architecture, change management, and organizational design. The focus is on delivering business design processes and methods as opposed to models and standards.

... Another challenge has been unifying the architects themselves into a single, cohesive community and creating a metamodel and deliverables that all disciplines can agree to and benefit from. ...building a common repository, which will have joint ownership across disciplines and its own governance team made up of representatives from the architecture community.

Lawson on EA supporting the Business

I think this is item is good and makes some key points

"... artifacts that are rigorous and approached as a science rather than as an art..."

"... instead of just discussing a business operating model through text ..."

"... you're not just documenting the business, you're analyzing the business and you're discovering quite a bit about the business ..."

"... they're not static deliverables. They're supposed to be living representations of the business and you should continue giving them attention and updating ..."

http://www.itbusinessedge.com/cm/community/features/interviews/blog/how-enterprise-architecture-can-support-the-business/?cs=47185&page=2

We also need to brings these concepts down stream into what business "analysts" and how requirements are discovered and elaborated e.g.

"... artifacts that are rigorous and approached as a science rather than as an art..." - what we need is are artefacts are rigorous and approached with semantic precision rather than as a story telling exercise in the "best seller list" book tradition

"... instead of just discussing a business operating model through text ..." - narrative is not always the best way of undertaking or recording analysis

"... you're not just documenting the business, you're analyzing the business and you're discovering quite a bit about the business ..." - and elaborating the Business Architecture as a part of defining requirements.

"... they're not static deliverables. They're supposed to be living representations of the business and you should continue giving them attention and updating ..."