Why Enterprise Architecture ?

Why Enterprise Architecture ?

A question which is often debated within Organisations is what is Enterprise Architecture (EA) and do we need it ?

The question is often due to a mis-understanding of what EA is and sometimes down to the fact the company may already have Solution Architects and are unclear in the distinction between the roles and of Solution Architecture and Enterprise Architecture.

What is Enterprise Architecture (EA)

Enterprise Architecture (EA) is a methodology which provides a structured,  co-ordindated, integrated and business driven approach to successful enterprise and IT transformation, which optimises costs, maximises business value and manages associated risks.

The Role of an Enterprise Architect

The role of an Enterprise Architect is complementary but distinct from that of a Solution Architect.

Consider a new hosing development each house has a building architect ‘Solution Architect’ responsible for the creation of the design, they work closely with the building developer ‘Technical Architect’  to produce detailed drawings, and to construct the house they use skilled craftsman ‘Domain Experts’, however each house must adhere to building regulations and standards ‘principles’ for use of external services ‘Enterprise Architecture’

The Enterprise Architecture works closely with the business to agree a target vision and establishes principles, re-usable standard architectures ‘building blocks’,  design blueprints and components  which support interoperability, governance and maximum ROI.

Enterprise Architecture (EA) Frameworks

An Enterprise Architecture framework describe a method for developing systems  in terms of a set of building blocks, and for showing how the building blocks fit together. There are a number of EA frameworks which can be used for developing a wide range of different architectures, some aligned to specific industries, government agencies, generic (Zachman) or be flexible (TOGAF)

EA Framework Examples include:

  • US Department of Treasury Enterprise Architecture Framework (TEAF)
  • US Federal Enterprise Framework (FEAF)
  • US Department of Defense Architecture Framework (DoDAF)
    • Previous frameworks include:
      • C4ISR  AF (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) Architecture Framework
      • US Department of Defense Technical Architecture Framework for Information Management (TAFIM)
  • UK Ministry of Defence Architecture Framework (MoDAF)  
  • Zachamn
  • The Open Group Architecture Framework (TOGAF)
Advertisements

Managing Organisational Change with Enterprise Architecture

The Role of the Enterprise Architect

As key change agents, Enterprise Architects are often critical in the success of organisational change, working closely with all areas of the businesses and IT to produce ‘As-Is’ architectures, developing ‘To-Be’ architectures and any intermediate transition architectures.

Enterprise Architects need to combine architecture and domain knowledge with other skills such as leadership, persuasion, negotiation, communication and the ability to ‘Sell’ the value of particular options to sponsors and key stakeholder so that their ‘shared’ vision can be realised.

Change Management

The Open Groups ‘TOGAF’  (Phase H: Architecture Change Management) and some other Enterprise Architecture (EA) frameworks include change management

TOGAF provides a comprehensive Change Management and describes it’s approach as:

“The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. This includes managing changes to the architecture in a cohesive and architected way.

This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment. When changes are identified, change management will determine whether to formally initiate a new architecture evolution cycle.

Additionally, the architecture change management process aims to establish and support the implemented enterprise architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment.

Monitoring business growth and decline is a critical aspect of this phase. Usage of the enterprise architecture is the most important part of the architecture development cycle. All too often the business has been left with an enterprise architecture that works for the organization of yesterday but may not give back sufficient capability to meet the needs of the enterprise of today and tomorrow.”

JP Kotter, a professor from the Harvard Business School, is a world-renowned leadership and organisation change expert http://www.kotterinternational.com/

In his 1995 book ‘Leading Change’, John introduced us to his Change Management process framework and the now famous concept of the ‘Burning Platform’.

His framework identified 8 steps to successful organisation change based on observations of where companies repeatedly go wrong and fail to meet their aspirations.

Kotters 8 Steps

The first three steps are about creating a climate for change

The next three steps are about engaging and enabling the whole organisation

The last two steps are about implementing and sustaining change

By using Kotters 8 step Change Management framework with Enterprise Architecture best practices we can deliver complex organisational changes to the business

I a future blog I will describe each of the 8 steps in more detail, enjoy

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Common Blockers to Technology Adoption

In this Blog I will share some issues and potential blockers to technology adoption I have seen,  and share steps which can be undertaken to address these and hopefully accelerate adoption.

Blockers are commonly categorised into 3 groups

People, Process & Technology

Screen Shot 2015-04-01 at 11.58.48

People

Personal and organizational barriers are a frequent causes for slow adoption; there can be many reasons for resistance, these can include:

  • Missing or weak executive Sponsorship
  • Lack of vision or poor communication.
  • Staff just don’t get it
    • What are the Business benefits?
  • Fear of Change
    • How does it impact me?
  • Silo’ed teams
    • Historic mistrust of other teams and or departments
  • Inadequate Training
    • Lack of confidence to use solution.

Department or individuals not on side can quickly become detractors and significantly impact your ability to move forward, once identified they need to be addressed.

Process

Internal company processes, procedures and standards can all be blockers or factors in delays for wider adoption.

  • Governance
    • Engineering standards
      • Does new solution comply with existing standards?
    • Financial chargeback models
      • Do existing models support this are they correct?
    • Solution ownership
      • Data center, development teams, business etc..
  • IT Service Management ITIL (Information Technology Infrastructure Library)
    • Change Management
      • How are changes approved and implemented
    • Configuration Management
      • How are configuration items managed
    • Request Fulfilment Process
      • How are new requests raised and approved
    • Incident Management Process
      • How are incidents categorised and managed

Technology adoption can sometimes be disruptive, old processes may need to be reworked or retired if no longer appropriate.

Technology

Enterprise level adoption requires that the technology not only works as expected but is compliant to internal policies.

  • Is the technology in-line with EA (Enterprise Architecture) Principles
  • Is the technology and business benefit understood
  • Is there a technology champion
  • Is there a clear vision of how the solution will be used
  • Does the solution satisfy a recognised business issue
  • Does the solution work the as expected

If any of the above are ‘No’ there is a risk that the technology will become ‘Shelfware’ and never expand out of it’s original deployment.


Key steps to Adoption

  • Establish a sense of urgency.
    • Senior leadership explains compelling need for business transformation
  • Form a powerful guiding coalition
    • Recruit key sponsors to drive change value proposition for technology and business transformation
  • Create a compelling vision
    • Establish business transformation strategy, driver and target technology vision.
  • Communicate vision
    • Develop detailed stakeholder management and communication plan
  • Empower others and remove obstacles
    • Establish strong governance organisation and build effective technical capabilities in critical areas
  • Create short term wins
    • Create incremental plans for technical delivery based on transition architectures.
  • Consolidate and build on change
    • Establish technology lifecycle and change management.
  • Institutionalise change
    • Establish technology as core for business and IT transformation, technical organisation, best practices & standards, recruitment & skills development etc…

Kotters 8 Steps for Change Management