Skip to content
Agile Enterprise Architecture
  • Home
  • Services
    • Remote Services
      • Looking for EA modelling?
      • Why Arch-as-a-Service?
      • Modelling-as-a-Service
      • Assess Arch Maturity Free
      • Arch Modelling Notations
        • Archimate model types
        • Quadrant model types
        • Canvas model types
        • UML model types
        • BPMN Model types
        • DMN Model types
        • ERD Model types
        • Structured Info types
        • Cisco model types
      • Arch Modelling tools
    • Consultancy Services
      • Digital Integration Services
      • Business Architecture
      • Health check services
        • Arch Risk Assessment
        • Arch Governance checkup
        • Arch Models health check
        • Arch Content health check
    • Cloud Hosting services
      • EA SaaS – Orbus iServer
      • EA SaaS – EVA Netmodeler
      • EA SaaS – Dragon1
      • Meta-Model Structuring
  • Blogs
  • About
    • Our AgileEA Business Model
    • Our AgileEA Principles
      • Open & Transparent
      • Value for money
      • Keep it simple
      • Love what we do
      • Efficient & effective
    • Location
Enterprise Architecture

Who should own Enterprise Architecture?

  • 2009-03-282018-05-08
  • by Charles

The clue about Enterprise Architecture ownership is in the title. One of the issues I see as an EA practitioner all the time is the fact that Enterprise Architecture typically falls within the IS/IT Department remit within many enterprise organizational structures and not where I believe it ought to be positioned. EA should be part of the Strategy Department under the CEO and therefore divorced from either the Supply or Demand side of the Enterprise, thereby governing from a neutral position and informing the executives of the enterprise. EA positioned within IS/IT it’s like having two opposing Lawyers in a court room where one of them is also acting as the Judge; the verdict is always only going to go one way.

Why is EA in IS/IT mostly? The reasons for the evolution of EA being owned within the IS/IT department are quite understandable. The practice of Engineering and Architecting systems and systems-of-systems stems primarily from the Technical domain rather than the Business domain, out of a need to build and supply rigorous software and hardware systems.

The business domain have used simpler diagrams to show concepts, to collaborate on ideas and thoughts, but till more recently the business have never had to be very rigorous other than in the financial sense. More recently the business domain is dealing with more formal business processes diagrams that generate working software, so the rigour is beginning, and so too is the understanding.

Whereas the Technical domain has relied on a far more rigorous diagramming notation to formally build and help implement systems. Architecture does not stop at diagrams; Requirements have to be formally managed and traced, Configurations of systems have to be managed, Change controls have to be managed, Testing, Hardware connectivity for LANs and WANs have to be formally managed, etc.

The common currency between the Supply and Demand has been money, time and power. All discussions have come down to the first two with the third making the final call. These are only the tip of the iceberg. Unfortunately none of these involve complexity and the buildup of “Enterprise Technical Debt“.

Hence the practice of building up Architectures and being able to Govern and manage complex systems has mostly evolved from the Engineering side. The Technologists have understood why this is important to them. They have built mechanisms to cope with complexity such as Abstractions, Visual Modelling, Configuration and Change Control management systems, Reusability, Services, Test, Build and Deployment automation, etc.

So with this in mind, if you look at an Enterprise from a Supply and Demand point of view, in general Business drive the Demand and Technology Supplies the solutions. On the demand side you would expect to see motivation, direction setting and strategy, which ties into the time and money available.

On the Supply side you’d expect to see a reply to that Demand given certain principles and constraints such as ensuring re-use, avoiding duplication of resources in terms of Servers, Data, Functionality, etc.

Put all this into a negotiation between Demand and Supply and somehow out of all of it, certain compromises get made on both sides.

Generally Business give up functionality and Technology gives up coherent Architecture. In order to control and regulate these conflicts of interest IS / IT departments have implemented Governance processes, at various levels, Programme and Project, Architecture, Service management, etc.

The challenge is that as the ever technically savvy Business submit Demands on the Technology Supply side, how can IS/IT possibly govern these compromises if they are not empowered to straddle both sides of the debate? An IS/IT based Architecture governance is not in a position to rule against the Business, particularly if the Business hold the purse strings and are the Demand “Customer”.

Consequently IS/IT want to make themselves look good by trying to deliver on time and within budget, and start compromising on their own principles by ignoring the Architecture governance outcomes, or offering endless Waivers and Dispensations. Many Supply side Risks and Issues are never feedback into the Business on the demand side, and even if they are fed back, many times it’s too late or the business cannot interpret the meaning. Ultimately the Enterprise is compromised over time.  The Enterprise Technical Debt builds up and builds up until all ability to make any change at all becomes impossible. Any change costs too much or takes too long. All Agility is lost.

Instead if a small Enterprise Architecture team of practitioners made up of Business Architect(s), Information Systems Architect(s) and technology Architect(s) are put into a “Strategy” team under the CEO, who liaise closely with the IT Solution Architecture team, and the Business subject experts then, the equilibrium should be restored. The IT Solution Architects should still remain under the CIO and not directly report to the “Strategy” (or some more meaningfully named) EA team. This assumes a lot of collaboration, communication and engagement between all parties. The “Strategy” EA team should have the necessary technical and business background to feedback the overall Risks in the business and thereby avoid the inevitable Enterprise Technical Debt build up over time.

AgileEA Process

Putting the Agile into an EA process (2007)

  • 2008-07-252018-05-08
  • by Charles

Abstract

In March 2007 Charles delivered his first talk about the Agile EA operational process at the Togaf Conference in Cape Town South Africa. Read up on the content here:

http://www.opengroup.org/capetown2007

http://www.opengroup.org/capetown2007/edwards.html

Download

pw2007-Togaf-PuttingThe’Agile’IntoAnEAProcess-V1.1.pdf

AgileEA Process

Building a case for an Agile Enterprise Architecture Process…

  • 2007-02-042018-05-08
  • by Charles

Abstract

This series of papers considers the case for enhancing the good work the Open Group contributors have already produced in TOGAF 8.1 [1], by defining an lean and mean Enterprise Architecture (EA) Practice Process that can be picked up and used with minimal tailoring to get an EA Practice started quickly.  Enterprise Architects starting a new practice say “There is so much to do and so much complexity. Where do we start? How do we move forward in a structured and well defined way, but still add value to the organisation quickly?”

The goal of this second paper is to suggest using existing standards to drive out solutions to the problems EA Practices face (as posed in the previous Part 1 paper). To suggest a set of standards upon which an Agile Enterprise Architecture Process could be more specifically defined. Processes to help Enterprise Architects get started quickly and easily.  Enhancements to the TOGAF process are to be based primarily on the newer and beneficial thinking Agile and Adaptive [10] principles, but on other influences as well.

Download

This can be downloaded in PDF form here: Agile Entperise Architecture V1.0 – part 2

AgileEA Process

Agile EA Operational Roles

  • 2008-04-262018-05-08
  • by Charles

Abstract – Agile EA Operational Roles

The subject of People’s jobs, Positions and Roles always tend to get somewhat confusing as there are such subtle differernces between them. However roles are useful in defining activities and responsibilities for those activities, so they need to be defined.

This paper explores each type and offers suggestions for how to organise an Agile Enterprise Architecture team based along the lines of Roles, but keeps the concept of positions and jobs.

Download

Version 1.00 can be downloaded here: Enterprise Architecture Practice Roles

Enterprise Architecture

The Enterprise Architecture Vacuum

  • 2008-08-292018-05-08
  • by Charles

Abstract

There is an Enterprise Architecture Vacuum. Architecture in computing and business is an often misunderstood concept. Many of those who work in Information Systems and Technology Departments do not necessarily come from a software or systems architecting and engineering (specifically coding) background. They find it difficult to fully appreciate many of the subtleties of Architecture because they do not have a Modelling or Systems thinking background.

This paper shows how due to misunderstanding the breadth and depth of the various architectural concepts it is easy to overlook a fundamentally important and strategic part of the Enterprise as a whole; in particular Enterprise Architecture.

Download

Version 0.04 can be downloaded here: Enterprise Architecture Vacuum-V0.04.pdf

Posts navigation

1 2

Categories

Tags

Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

Recent Posts

  • Announcing Our Train44Ir.org charity 2020-04-24
  • Data Fabric Framework – Archimate 3.0 model 2018-05-10
  • OpenStack Cloud Metering in Archimate – Part 10 2017-04-28
  • OpenStack Cloud Orchestration in Archimate – Part 9 2017-04-28
  • OpenStack Cloud Identity in Archimate – Part 8 2017-04-28
  • OpenStack Cloud Object Storage in Archimate – Part 7 2017-04-28
  • OpenStack Cloud Images in Archimate – Part 6 2017-04-28
  • OpenStack Cloud Block Storage in Archimate – Part 5 2017-04-27
  • OpenStack Cloud Compute in Archimate – Part 4 2017-04-27
  • OpenStack Cloud Networking in Archimate – Part 3 2017-04-27
  • OpenStack Cloud Dashboard in Archimate – Part 2 2017-04-27
  • OpenStack Cloud in Archimate – Part 1 2017-04-27
  • Hosting and Cloud Software Delivery modelled in Archimate 2017-04-19
  • Why do Architecture Maturity Assessments regularly? 2017-03-22
  • Archimate 3.0 introductory basics videos 2017-02-28
  • Example Services and Capabilities with Meta-Model 2014-11-09
  • Why a CV in Archmate? 2014-07-14
  • Charles Edwards Archimate CV 2014-07-10
  • EA Conference 2009 – Agile EA: A Step change is required 2009-06-13
  • Who should own Enterprise Architecture? 2009-03-28

Previous Posts

Our Twitter Feed

My Tweets

Recent Comments

    Translate site

    Tag Cloud

    Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

    Blogs about

    AgileEA Process Blogs Charity Cloud Openstack Enterprise Architecture Health checks Information & Data Modelling Strategy Technical Debt Thoughts Use Cases

    Our Twitter Feed

    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2021.
    Theme by Colorlib Powered by WordPress
    Agile Enterprise Architecture
    Proudly powered by WordPress Theme: Shapely.
     

    Loading Comments...
     

    You must be logged in to post a comment.