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.

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.

Could you imagine running a medium to large financial department in a business using only spreadsheets instead of a proper Accounting system in this day and age? Hardly.

As a practicing Enterprise Architect it never ceases to amaze me at how everyone can see the need for an Accounting System within an Enterprise, no matter the size of the company, but by and large completely fail to recognise the need or benefits of an Enterprise Architecture System. Is it because Accounting systems have become the norm and are embedded in the culture of the way we do business?

This paper compares the two items to see how far apart they really are, and help swing the culture of business towards “accounting” for the architecture of the enterprise as part of the norm.

Download

ChangingTheCulture-EnterpriseArchitectureSystems-V0.03.pdf

The post Changing The Culture – Enterprise Architecture Systems appeared first on Agile Enterprise Architecture.

This talk was given in New York City at the International Association of Software Architects (IASA) on Friday the 23rd May 2008 by Roger Sessions. He has kindly given us permission to publish his talk here.

The presentation introduces Enterprise Architecture and the does a comparison is between: Zachman, TOGAF, FEA, AgileEA, VPEC-T and SIP.

Download

This presentation can be downloaded in PDF form from here: An Introduction to the Major EA Methodologies

The post An Introduction to the Major EA Methodologies (2008) appeared first on Agile Enterprise Architecture.