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

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