What shape is your Architecture practice in?

Do you know what shape your company’s Architecture team are in health-wise? You should test your team against some form of Industry or third-party benchmark. Architecture Maturity Assessments should be like clock-work. Once a year.

• Measuring business architecture capability maturity
• Gartner.com – Scoring Enterprise Architecture
• ErWin – Why Enterprise Architecture Needs Maturity Models

The post Why do Architecture Maturity Assessments regularly? appeared first on Agile Enterprise Architecture.

This was the presentation given at the RealIRM EAC 2009 in London.

The title was Agile Enterprise Architecture: A Step change is required.

Download

Get the .PPT here (4.2 Mb)

The post EA Conference 2009 – Agile EA: A Step change is required appeared first on Agile Enterprise Architecture.

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.

The post Who should own Enterprise Architecture? appeared first on Agile Enterprise Architecture.

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

The post Putting the Agile into an EA process (2007) appeared first on Agile Enterprise Architecture.

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

The post Building a case for an Agile Enterprise Architecture Process – Part 2 appeared first on Agile Enterprise Architecture.

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

The post Agile EA Operational Roles appeared first on Agile Enterprise Architecture.

How does anyone coming in fresh, not having seen this Enterprise Architecture Operational Process before, start to get into understanding what the AgileEA operational Process is all about?

This paper gives an analogy we all understand; a Pub Menu. This leads you into an equivalent choices in AgileEA so that you get the general idea of what the phases and capabilities within the process are and how to configure them to suit your own situation.

Download

This paper can be downloaded in PDF form from here: PubMenuAnalogyForAgileEA-v0.01.pdf

The post Pub menu analogy for AgileEA appeared first on Agile Enterprise Architecture.

Exploring Services and Requirements – Part 2

A series of three papers exploring the tie up between gathering requirements for a Services world and how this overlaps with the Enterprise Architecture world. They were also published and commented on the www.requirementsnetwork.com (RQNG) website in 2008.

Download

Exploring Services and Requirements Part 2 – v0.09

The post Exploring Services and Requirements – Part 2 appeared first on Agile Enterprise Architecture.

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

The post The Enterprise Architecture Vacuum appeared first on Agile Enterprise Architecture.

Using the concept of SCRUM from the software development world, we modified it to suit the daily life of the Enterpise Architect in an Enterprise Architecture practice. This paper describes the concepts around the idea.

This paper was done in a rush and needs refinement, so please excuse it in some areas, but the point was to get the concept across quickly.

Download

AEA SCRUM based EA Planning Process

The post AgileEA Scrum based planning process appeared first on Agile Enterprise Architecture.