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)

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The Data Supply Chain

The Data Supply Chain

 

During the late 80’s early 90’s I worked in the high tech electronics industry, more precisely ‘Manufacturing Supply Chain’. This was a time of great change with IT systems delivering integrated Finance and MRP solutions and the start of the ubiquitous use of desktop computing, who remembers using Lotus 123, Harvard Graphics & WordPerfect ?

 

But the biggest change in the manufacturing supply chain came from Japan, with ‘Kanban’, ‘Jidoka’, ‘Andon’ and other and Japanese processes and manufacturing terms  becoming common place.

As a MRP (material resource planning) engineer I had objectives all based around productivity, reducing costs and improving the time taken to deliver products to customers. eg.

  • Reduce inventory costs by $$$
  • Reduce delivery time to customers by X weeks
  • Increase throughput / productivity by Y
  • Improve customer satisfaction and quality x%

The objectives were challenging but attainable, by analysing the end-to-end supply chain and working with key stakeholders (suppliers, buyers, stores, assembly lines and QA) I was able to identify opportunities to reduce the overall product lead times.

These included:

  • Process re-engineering e.g. moving to ‘JIT’ Just-In-Time manufacturing
  • Collapsing BOM’s (Bill of Materials) and introducing phantom part numbers to reduce lead times by avoid the need to repeatedly book items in and out of stores.
  • The creation of local assembly line stores for commonly used items to reduce the volume of stores transactions.
  • Negotiating regular deliveries of materials and components in line with demand reducing the value of the inventory and WIP (Work In Progress).

The Delphix Data Supply Chain

Roll forward 25+ years and the IT industry has changed and matured to something unrecognisable, however IT has been playing catch-up to address some of the same challenges that manufacturing had all those years ago.

Cost Reduction

With Delphix customers are realising significant cost benefits typically seeing a 10x reduction in non-production storage,  a reduction in the number of database server and licences by improved asset utilisation and management, as well as numerous agility savings.

Accelerated Time to Market

The Delphix ‘Self Service’ features are enabling application development teams to reduce project time scales and accelerate time to market, by taking all the wait times and delays due to the hand-offs between the various IT teams e.g. system administrators, storage admininstrators & DBA’s out of the process.

Increase Productivity and Throughput

With Delphix application development and test teams are accelerating their movement from Waterfall to Agile, Scrum or Kanban based SDLC’s (software development lifecycle), increasing productivity and throughput. This is achieved by removing the delays and storage constraints enabling developers to get timely access to their own full size copy database rather than having to share databases and coordinate testing with multiple teams.

Improved Quality and Customer Satisfaction

Application development teams that have embraced Delphix are seeing the benefits of using full size data sets, with visible improvements in quality and customer satisfaction measures, a reduction in the volume of Production incidents and enhanced MTTR (mean time to resolve) for data related problems. 

Manufacturing & Data Supply Chain

In the table below you can see the business drivers and objectives are common for both Manufacturing and the Data Supply Chain, what’s change now is for the first time we have the tools and processes in place to deliver an end to end Data Supply Chain solution.

Data Supply Chain