Which came first the Enterprise Architecture or the Requirements?

On one particular programme the question arose whether to create the "Enterprise Architecture" or the "Requirements" first has been a matter of great debate. On the one hand, the organisation in question did not have an Architecture and yet the organisation's aim was to engage in a major transformation. There was no baseline, no standard operating procedures nor were there any governance or directive documents.

Due to time limitations, the architecture team decided that the first thing that they would do would be to capture the Enterprise Architecture. They followed an academically correct method in working out how the organisation was structured, their roles, responsibilities, business rules and processes. It was a classic engagement.

The only problem was, that they did not capture the requirements as they were going along, even more so, they did not use the customer needs and desires to form the "germ" requirements.

What transpired was that they created an AS-IS Architecture and extrapolated this to derive the deltas that would make up the TO-BE Architecture. While this was extremely clever, it was prohibitively expensive in that every functional area was exhaustively explored and the client staff were engaged in a whole plethora of workshops. The Enterprise Architecture developed consisted of very detailed series of models and to all intents and purposes it could have worked.

But.....

There is always a but.... In the haste to capture all the information, the cardinal rule of Enterprise Architecture was forgotten. That there needs to be an agreement on method, meta model, consistency in modelling approach, agreed conventions and structure to coordinate the use of key and common elements in a repository. What ensued was duplication and multiple core objects and architecture elements, inconsistency in structure and so many models that actually you couldn't see the wood for the trees and finding meaningful models was proving to be difficult.

One aspect for lack of cohesion can be found in the human dimension. The architects were not working as a cohesive team. An engagement with a number of architects require discipline, control and a central point who will be responsible for ensuring that the architecture is consistent.

Nevertheless, this does not change the fact that these engagements can produce an inordinate number of models and as true to form, when they were analysed to form requirements, even though they had captured the behaviour and structure of the intended architecture it still lacked some of the qualitative dimensions in terms of performance, non functional and decorative aspects. The result was a well formed enterprise architecture, however, the requirements had to be developed on the gallop and quality suffered. The result was that the client was not pleased. They had bought into the idea that a perfectly formed

To bring the engagement back on track a Lean approach was taken, to select the key models needed for the development of requirements and the structuring of Enterprise Level requirements from which system, operational and business requirements would flow.

The Lean method states that before an Enterprise Architecture is undertaken that there should be requirements. In many cases these will form the parameters and scope of an engagement and will determine the key purpose of the architecture and organisational strategic goal. These requirements need to be measurable in order to understand how the Enterprise Architecture can be judged as to whether or not it is fit for purpose. These requirements direct the development of an Enterprise Architecture and subsequent prioritisation and specification of requirements at all levels of the enterprise.

It must be said that Lean has proved to have been a very useful method to develop an Enterprise Architecture to create a coherent set of models with associated requirements in a fraction of the time taken for the programme above. Granted it did not try and boil the ocean, but took discrete areas that needed treatment and brought these into a coherent set of models that could be integrated into the Enterprise continuum.