Next Generation - applying Enterprise Architecture to managing projects

Enterprise Architecture is evolving; the new generation of Enterprise Architecture methods finally achieving their goals to slash project times and reduce costs for organisations. This is critical as companies strive to increase their competitive advantage, optimise their operations, reduce costs and respond faster to market demands. To that end, Enterprise Architects have positioned themselves to provide advice on using IT as a strategic tool as part of the strategic decision making process with company directors.

Gartner heralds the impact of Enterprise Architecture (EA) on delivering business value through the strategic use of IT.

“Overwhelmingly we find EA practitioners focused on delivering on business value and strategic transformation," said Philip Allega, managing vice president at Gartner. "Gone are the days of just 'doing EA' with little value or impact. Sixty-eight percent of organizations surveyed stated that they are focusing their EA program on aligning business and IT strategies, delivering strategic business and IT value, or enabling major business transformation." [1]

Enterprise Architecture is supporting the development of IT operations and infrastructure into the new “Agile” paradigm.  Enterprise Architecture needs to not only deliver value but accelerate projects, operations while speeding up delivery and time-to-value.  Nautilus-PM [2] has chosen the open  EA method to accelerate project management and development as it offers the most pragmatic approach to delivering incremental project outcomes without having to undertake the long winded processes commonly found in the traditional software and enterprise architecture development methods. The future is “Agile” with thought-leaders, such as Gartner predicting that by the end of 2012, agile development methods will be used on 80% of all software development projects [3]..

The Visual Enterprise Architecture shapes the project activities and approach. “Agile” demands a departure from the traditional waterfall approach to systems engineering that saw monolithic system development and implementation that took high level analysis through to detailed design. The complications arose as time elapsed and changes would require repeating analytical and design cycles, which proved to be cumbersome and difficult to manage.  The “Agile” incremental approach to developing systems focuses on delivering prioritised clusters of system functionality for faster utilisation while planning subsequent increments of reprioritised functionality as the capability need grows. This enables a company to make operational use of these systems earlier, while giving it the flexibility to respond and grow in response to market and customer demand.  A change in market demand can affect the prioritisation assigned to system functions, which can be brought into operation sooner if so required or can be postponed in favour of higher prioritised functionality. This approach has been used effectively in public sector organisations to streamline operations, reduce systems and infrastructure costs while enabling personnel to deliver greater value for money (VfM).  The systems procurement and acquisition processes in public sector organisations have been scrutinised and found to cost too much money. Frequently, by using the traditional systems engineering methods, functionality and systems are obsolete by the time that they are delivered. Evaluations has found that the systems have been too late, over budget and lacking in the functional richness needed to provide user satisfaction.

The US DOD insist on an "evolutionary acquisition" approach for all identified natural systems, i.e. they buy a few items or the initial elements of the product, use it, learn from its features or performance, then develop it further, rather than trying (and failing) to specify all details from the outset [4].

The birth of the “Agile” approach to EA has not been without tears.  Similarly, when the Object Oriented paradigm was introduced the “old guard” custodians of IT standards regaled “It will never work”. Agile has received the same cynicism until the weight and burden of demonstration has demanded a rethink. It is not surprising that with the weight of investment into the traditional methods of developing EA that there would be a resistance to the newer “disruptive” approaches. This has been a familiar pattern: companies who invested heavily in mainframe infrastructure resisted moving towards a flexible, open architecture due to their perceived investment in these old systems, it is a matter of time before the cost of maintaining older legacy systems outweigh the advantages realised by new methods, structures and systems.

Fortunately for organisations, the adoption of Enterprise Architecture to visualise Project timelines and roadmaps means that they do not lose their investment into their infrastructure but are able to redeploy resources and applications to leverage greater value and take control of their system portfolio.  

Enterprise Architecture builds on the creation of blueprints and enterprise maps that visualise Enterprise Views of concepts, issues, principles and key goals to build a common understanding across stakeholder groups. Having a unified view that supports discussions and decisions ensures the common ground for implementing evolving information systems and business processes.  The Nautilus project CPM (critical path method) plans plug into this living enterprise view of road-mapping and time-lines.

While this approach may seem to be common sense to Boards of Directors, Funders and other Stakeholders, it is a new direction and a new paradigm for EA: This is The Visual Age. We have departed from the strict demarcation of Business – IT – Technical and Implementation Architectural views that have been promoted by methods and frameworks such as TOGAF. It advocates a leaner, compact and multi dimensional approach more akin to the Checkland [5] soft systems methodology with its World-view (Weltaanschaung) and focus on stakeholders, client views and business value.  Engagement with business and IT communities and provision of a common natural language engenders strategic alignment and seamless threads from business vision and goals through to operations and infrastructure. The organisation begins to work and think like a total organism.

Through dialogue with key stakeholders and executing an “Agile” approach organisations and project boards enjoy results not within the average 12 months [6] that was the usual time taken using previous methods, but within 3 months. EA provides key actionable products and blueprints using language that management, developers and the wider community understand.   This accelerated approach to visualising the key concerns, issues, concepts and requirements speed up decision making. The concepts illustrated relate to multi dimensional aspects of the enterprise. They represent aspects that need to be addressed and are illustrated in an “AS-IS” current picture of problem areas, and “TO-BE” solution concepts and goal situation.  Each dimension is then worked down into their respective areas, such as information, business process, infrastructure and technology while maintaining correlation and interdependencies.

In summary, the new generation builds upon the natural world, is aligned with the demands and lessons learned from the traditional systems engineering while providing new agility to corporations and organisations.

Nautilus Project Management

Nautilus-PM is a niche innovation SME development consultancy, relying on 34 years experience in the delivery of multi disciplinary projects with EU or government funding, using CPM (critical path method) and CIM (continuous inspection monitoring) systems.  

Nautilus PM is a separate strategic business unit within EU-Reconnect Ltd, a major contributor in transferring conventional proven engineering design & construction management techniques into IT enterprise architecture methods. In its profile Nautilus-PM relies heavily on the Agile EA method for accelerating the journey between SME product & services concept and commercialisation – Routes to Funding and Routes to Market.

Nautilus-PM can therefore be best identified as a technical and commercially focussed consultancy operation, dedicated to assist SMEs with boots-on-the-ground sustainable development. Its’ services include the following:

·         Levelling obstacles and potential entry and exit points in business development, assisting SMEs to compete with cognisant solutions; foundation research, collaboration and routes-to-market on the basis of cooperation, and exploring co-evolution of societal and technological change.

·         Connecting SMEs with the innovation landscape of the EU and Government, and assistance with creating collaboration with Large Enterprises and Universities, and through obtaining development funds through Eurostars, smart grants, innovation vouchers and R&D tax credits and Patent Box support

·         Using innovative IT, EA tools, i-visualisations and lean project management of development programs, enabling effective routes to credits and routes-to-market.

·         Introducing initiatives aimed at increasing market growth and max ROI and access to EU funding (up to 75%)

·         Assisting SMEs as pathfinder toward practical industrial technologies supporting:

o   Advanced manufacturing and processing

o   Research and innovation (policy, rules, routes and ethics)

o   Sustainable development and international cooperation

o   'Access to funding/risk finance, inducement prizes (participation in equity financing)

o   Practical, easy-to-apply Information & Communication Technology, including securitisation

o   Innovation & change program/project monitoring and evaluation

---

1 STAMFORD, Conn., January 15, 2013, Gartner Says Enterprise Architecture Practitioners Significantly Influenced $1.1 Trillion http://www.gartner.com/newsroom/id/2303215

2 Nautilus-PM Project Management method incorporating CPM www.nautilus-pm.eu

3 PMI Agile Certified Practitioner (PMI-ACP)®, http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx

4 UK Parliament, Defence Acquisition, Chris Donnelly, Session 2012-2013 http://www.publications.parliament.uk/pa/cm201213/cmselect/cmdfence/writev/acquisition/m15.htm

5 Checkland, Peter B. Systems Thinking, Systems Practice, John Wiley & Sons Ltd. 1981, 1998. ISBN 0-471-98606-2

6 Example of roadmap for traditional Enterprise Architecture: http://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html

Enterprise Architecture Fatigue

Enterprise Architecture Fatigue

Interesting discourse with a new client. They have been through numerous attempts to establish Governance using Enterprise Architecture and every time they find themselves swamped with extremely clever people who produce copious quantities of Enterprise Architecture documents, diagrams and hold ever increasing numbers of meetings. Meanwhile, when the client asks for tangible support material needed for making Architectural Decisions and to support implementation, information management and other operational issues, nothing is found.

The client complained that in the past numerous teams have tried to "Boil the Ocean" and model as many artefacts, creating system views that were academically perfect, however it seemed that the diagrams just didn't meet the needs of the client or their stakeholders.

Another way

That brings me back to another way. I explained to the client how this works, that first of all we work out a list of their core requirements and needs as this frames the types of diagrams that need to be developed. It is all about purpose and keeping to the scope, understanding the stakeholders, their needs and their roles, which dictate how they use architecture in their organisational and operational roles.

The work of setting up a Governance Framework has not been helped when clients have been through these experiences and it is harder to win back confidence. What does help is explaining how focussing on key diagrams developed on the basis of the Core Architecture Requirements and Needs, guided by Architectural Principles.

The client has a set of Architecture Principles, which they were quite happy to disect and analyse into constituent concepts. The approach to Principles in TOGAF can at times consist of best intentions or be considered a "wish list" while it is more useful to look at design guidelines that inform real and practical strategic direction. When looking at a Principle, it is worth asking the "so what" question.

Basic Rules for formulating principles 

1. Name the concept or phenomenon that has been identified as a target, and break down the contributing aspects, lowest common denominators, factors that describe the phenomenon in terms of root causes and symptoms.
2. Give the principle a name tag, makes it easier to name and nail. Then add relationships to the root causes - an atomic factor could be a factor in a number of principles. 
3. For effective communication purposes try to find or create a picture showing exactly what is stated in the short statement - start a pattern books (the good, the bad and the ugly)
4. Do not mix derived design rules or policies with the principle itself. It is obvious you need policies and rules to take the principle in to account once you know of the principle. But rules and policies are not part of the principle!

Take a Security Principle By using two staged authentication and authorisation mechanisms in accessing company systems from external trusted systems it is ensured that only legitimate system access is allowed so that unauthorised access is prevented and critical information and resources are protected.

These principles are then analysed and devolved down into logical patterns for concepts that will guide implementation and that will be used for underpinning Architecture Governance decisions and evaluating design choices.

Governance Artefacts

 Gradually, the Principles and Patterns (Concepts) are starting to provide artefacts that support Governance and provide means to measure compliance with policies and to start identifying divergence. This is a perfect opportunity for identifying where dispensation needs to be allowed for exceptional circumstances and to schedule initiatives for bringing these systems or operations back under compliance. Sometimes an exception is needed in operationally critical circumstances or when technology is not mature enough to cope with the rigours demanded for secure operations. In these cases extra measures need to be put into place to guarantee the integrity of the wider system, such as a DMZ (demilitarized zone).

This approach has been a voyage of discovery for the client. Their first instinct was to design the Architecture using a "Bottom Up" approach by mapping out the system inter-connectivity and mapping out the interfaces and information exchanges.  While this at least shows current landscape and is an opportunity to identify where there are discrepancies, it does require some analysis in the light of its compliance to the desired principles and patterns. It does provide an opportunity to start identifying areas that need transformation and to plan activities to bring about compliance.

More importantly is the ability to keep focusing stakeholders on their roles, responsibilities and their involvement in the Governance process and in reviewing and agreeing models. Enterprise Architecture will be seen as an enabler as stakeholders are impressed with the relationship between compliance, policy, architecture diagrams and standards.

So we have come a long way, in a relatively short time and hope that Enterprise Architecture will be seen as a useful support tool for managing systems

Enterprise Architecture - Death by Meta Models

Last week I absolutely astounded having read a project report for a follow on Enterprise Architecture engagement that a former colleague had undertaken after I had previously set up the Enterprise Framework and the strategic direction for engagement with the implementation projects.

It had been a total mystery why the Enterprise Architecture practice in the organisation not only failed to take off but imploded so badly that the very reputation of Enterprise Architecture as a business transformation and project support vehicle had been totally destroyed. If you spoke to anyone in the organisation about Enterprise Architecture you would meet the utmost derision. It was seen as a waste of time, space and potentially dangerous. This was time for a post-implementation analysis to find out the reasons for this disaster.

A little background:

The Director in charge of the organisation had originally engaged the Enterprise Architecture Project as a mechanism to identify interdependencies between systems and areas where projects were delivering the same functionality and the organisation was therefore not only paying twice but it was causing confusion and duplication in the application landscape. We mapped out a framework that illustrated how the organisation is constructed with its strategic goals, business activities, functions and the underlying applications/systems and bearers. "Finally", said the Director, "I can see what my enterprise looks like." The point was that the Project Support Office could now analyse the Enterprise to see how a project impacts other projects and systems in development and operations and identify where there are issues that a project has to watch and subscribe to (watch and brief).

As far as we were concerned, the Project Support Office were working with the Enterprise Architect's Office to plan the evolution of the Enterprise. The Implementation and Delivery teams were engaged, they were finally given a Project Start Architecture, which provided them with a context in which they were going to start building their solutions and prepare them for their Architecture Design Review.

So what went wrong? Why did it all go so badly awry?

The problem was that the next phase of the project was headed by an Enterprise Architect who had all the qualifications of engineering, system engineering, architecture frameworks.... but absolutely no experience of operational or implementing systems in live enterprises. Consequently, the work undertaken was drawing up myriads of meta-models, concept models, ontologies, taxonomies and the end result?

While the report read like an academic document of some note, the Implementation and Delivery teams, Project Support Office and more importantly the Director saw that these diagrams did not address their key critical questions. It did not provide them with the framework to be able to analyse the root cause of issues, the disconnects or duplications or overlaps in system functionality.

The Outcome:

The Director came to the conclusion that while the Enterprise Architecture approach initially showed promise, it delivered too little, had no prospects of delivering value, confused people, irritated people and was a huge waste of time.
The Enterprise Architect's Office was disbanded, the Project Support Office was  dissipated and so a total of 14 people were removed from their position and redeployed. The responsibility was given to the Implementation and Delivery Teams to work out their interdependencies themselves. The Director decided that they were better off going the way they were than by keeping 14 people diddling around with petty meta, meta, meta-models.

 The Lessons Learned:

• Enterprise Architecture needs to be championed by a business user, with a clear understanding of the goals of the business user. Lose the championship and support of the business user and the Enterprise Architecture will not go anywhere;
• Produce useful artefacts that support decision makers and the wider community. If an Enterprise Archtiecture cannot be used, it will be discarded and disbanded.
• This is no time for pure academics - nobody is going to jump up and down with delight at being presented reams of meta models, ontologies and other indirect and obtuse products where the stakeholders can't see any direct value. 
• We need to think along the line of business value, what can we deliver, how can we exploit the models that we are deriving to support projects, decisions, to support transitions.
• We need to heed the warning not to create diagrams, models, drawings for our own benefit, we need to keep our minds on the meaning and support to the wider stakeholder community and to ensure that we have an absolute justification for each diagram developed.

Turning around the Team

Without doubt the biggest contributing factor to success on projects where I've been engaged as an Enterprise Architect is the human dimension. Bringing a method that people can buy into, in a language that they understand and then reinforcing this with a positive atmosphere.

One of the most rewarding experiences was seeing a situation where a large Dutch governmental organisation was known to have a culture that was described as a "Snake Pit" and sure enough, when I joined the team the fangs and the venom came out. Two consultants from Sogeti were so distraught that they left the buildings in tears. I had the good fortune of having come from certain industries in the United Kingdom where one develops an immunity to these antics and personal character assassinations and in fact one finds them rather amusing. However, as amusing as they may well be, especially witnessing the increasing ire and frustration in certain individuals who found that all their ploys were simply not working, as I said, as amusing as it may have been this was not going to be a good recipe for collaborative cooperation.

The Dutch culture lends itself to cooperation and collaboration. There are distinct Polder Model whereby people respectfully listen to each other, define their roles, expectations, goals and their cooperation agreements. It was a fascinating and most rewarding experience. However, in certain institutions this does not work.

What did help was the Lean approach to defining roles and responsibilities, which empowered the antagonists and slowly they were taken up with working towards building their own place in the organisation. The point being that these, far from being negative people, were people who had not been taken along the journey as the organisation was transforming. They had valuable skills, knowledge and could see shortcomings that could, in their mind, disrupt the status-quo of their own lives and existence. Actually being able to listen to their concerns, map them out to the strategic and subsequent system, business and information views helped to shine a light on the risks and the way that they would be addressed.

I do hope that they no longer hate me as intensively as they did to begin with, As a consultant, an invader, it is sometimes our role to provide a living target against which all blame, ailments and venom can be thrown. The most rewarding aspect of this is in winning people's trust as one among equals and to empower them to forge a future where they can see themselves comfortably grow.  And so, like Don Quixote, we move on to fight the next giant.

Next Generation - applying Enterprise Architecture to managing projects

Enterprise Architecture is evolving; the new generation of Enterprise Architecture methods finally achieving their goals to slash project times and reduce costs for organisations. This is critical as companies strive to increase their competitive advantage, optimise their operations, reduce costs and respond faster to market demands. To that end, Enterprise Architects have positioned themselves to provide advice on using IT as a strategic tool as part of the strategic decision making process with company directors.

Gartner heralds the impact of Enterprise Architecture (EA) on delivering business value through the strategic use of IT.

“Overwhelmingly we find EA practitioners focused on delivering on business value and strategic transformation," said Philip Allega, managing vice president at Gartner. "Gone are the days of just 'doing EA' with little value or impact. Sixty-eight percent of organizations surveyed stated that they are focusing their EA program on aligning business and IT strategies, delivering strategic business and IT value, or enabling major business transformation." [1]

Enterprise Architecture is supporting the development of IT operations and infrastructure into the new “Agile” paradigm.  Enterprise Architecture needs to not only deliver value but accelerate projects, operations while speeding up delivery and time-to-value.  Nautilus-PM [2] has chosen the Agile EA method to accelerate project management and development as it offers the most pragmatic approach to delivering incremental project outcomes without having to undertake the long winded processes commonly found in the traditional software and enterprise architecture development methods. The future is “Agile” with thought-leaders, such as Gartner predicting that by the end of 2012, agile development methods will be used on 80% of all software development projects [3]..

Visual Enterprise Architecture shapes the project activities and approach. “Agile” demands a departure from the traditional waterfall approach to systems engineering that saw monolithic system development and implementation that took high level analysis through to detailed design. The complications arose as time elapsed and changes would require repeating analytical and design cycles, which proved to be cumbersome and difficult to manage.  The “Agile” incremental approach to developing systems focuses on delivering prioritised clusters of system functionality for faster utilisation while planning subsequent increments of reprioritised functionality as the capability need grows. This enables a company to make operational use of these systems earlier, while giving it the flexibility to respond and grow in response to market and customer demand.  A change in market demand can affect the prioritisation assigned to system functions, which can be brought into operation sooner if so required or can be postponed in favour of higher prioritised functionality. This approach has been used effectively in public sector organisations to streamline operations, reduce systems and infrastructure costs while enabling personnel to deliver greater value for money (VfM).  The systems procurement and acquisition processes in public sector organisations have been scrutinised and found to cost too much money. Frequently, by using the traditional systems engineering methods, functionality and systems are obsolete by the time that they are delivered. Evaluations has found that the systems have been too late, over budget and lacking in the functional richness needed to provide user satisfaction.

The US DOD insist on an "evolutionary acquisition" approach for all identified natural systems, i.e. they buy a few items or the initial elements of the product, use it, learn from its features or performance, then develop it further, rather than trying (and failing) to specify all details from the outset [4].

The birth of  the “Agile” approach to EA has not been without tears.  Similarly, when the Object Oriented paradigm was introduced the “old guard” custodians of IT standards regaled “It will never work”. Agile has also received the same cynicism until the weight and burden of demonstration has demanded a rethink. It is not surprising that with the weight of investment into the traditional methods of developing EA that there would be a resistance to the newer “disruptive” approaches. This has been a familiar pattern: companies who invested heavily in mainframe infrastructure resisted moving towards a flexible, open architecture due to their perceived investment in these old systems, it is a matter of time before the cost of maintaining older legacy systems outweigh the advantages realised by new methods, structures and systems.

Fortunately for organisations, the adoption of Enterprise Architecture to visualise Project timelines and roadmaps means that they do not lose their investment into their infrastructure but are able to redeploy resources and applications to leverage greater value and take control of their system portfolio.  

Enterprise Architecture builds on the creation of blueprints and enterprise maps that visualise Enterprise Views of concepts, issues, principles and key goals to build a common understanding across stakeholder groups. Having a unified view that supports discussions and decisions ensures the common ground for implementing evolving information systems and business processes.  The Nautilus project CPM (critical path method) plans plug into this living enterprise view of road-mapping and time-lines.

While this approach may seem to be common sense to Boards of Directors, Funders and other Stakeholders, it is a new direction and a new paradigm for EA: This is The Visual Age. We have departed from the strict demarcation of Business – IT – Technical and Implementation Architectural views that have been promoted by methods and frameworks such as TOGAF. It advocates a leaner, compact and multi dimensional approach more akin to the Checkland [5] soft systems methodology with its World-view (Weltaanschaung) and focus on stakeholders, client views and business value.  Engagement with business and IT communities and provision of a common natural language engenders strategic alignment and seamless threads from business vision and goals through to operations and infrastructure. The organisation begins to work and think like a total organism.

Through dialogue with key stakeholders and executing an “Agile”  approach organisations and project boards enjoy results not within the average 12 months [6] that was the usual time taken using previous methods, but within 3 months. Enterprise Architecture provides key actionable products and blueprints using language that management, developers and the wider community understand.   This accelerated approach to visualising the key concerns, issues, concepts and requirements speed up decision making. The concepts illustrated relate to multi dimensional aspects of the enterprise. They represent aspects that need to be addressed and are illustrated in an “AS-IS” current picture of problem areas, and “TO-BE” solution concepts and goal situation.  Each dimension is then worked down into their respective areas, such as information, business process, infrastructure and technology while maintaining correlation and interdependencies.

In summary, the new generation builds upon the natural world, is aligned with the demands and lessons learned from the traditional systems engineering while providing new agility to corporations and organisations.

Nautilus Project Management

Nautilus-PM is a niche innovation SME development consultancy, relying on 34 years experience in the delivery of multi disciplinary projects with EU or government funding, using CPM (critical path method) and CIM (continuous inspection monitoring) systems.  

Nautilus PM is a separate strategic business unit within EU-Reconnect LLP, a major contributor in transferring conventional proven engineering design & construction management techniques into IT enterprise architecture methods. In its profile Nautilus-PM relies heavily on tAgile EA method for accelerating the journey between SME product & services concept and commercialisation – Routes to Funding and Routes to Market.

Nautilus-PM can therefore be best identified as a technical and commercially focussed consultancy operation, dedicated to assist SMEs with boots-on-the-ground sustainable development. Its’ services include the following:

·         Levelling obstacles and potential entry and exit points in business development, assisting SMEs to compete with cognisant solutions; foundation research, collaboration and routes-to-market on the basis of cooperation, and exploring co-evolution of societal and technological change.

·         Connecting SMEs with the innovation landscape of the EU and Government, and assistance with creating collaboration with Large Enterprises and Universities, and through obtaining development funds through Eurostars, smart grants, innovation vouchers and R&D tax credits and Patent Box support

·         Using innovative Enterprise Architecture methods and tools, i-visualisations and lean project management of development programs, enabling effective routes to credits and routes-to-market.

·         Introducing initiatives aimed at increasing market growth and max ROI and access to EU funding (up to 75%)

·         Assisting SMEs as pathfinder toward practical industrial technologies supporting:

o   Advanced manufacturing and processing

o   Research and innovation (policy, rules, routes and ethics)

o   Sustainable development and international cooperation

o   'Access to funding/risk finance, inducement prizes (participation in equity financing)

o   Practical, easy-to-apply Information & Communication Technology, including securitisation

o   Innovation & change program/project monitoring and evaluation

---

1 STAMFORD, Conn., January 15, 2013, Gartner Says Enterprise Architecture Practitioners Significantly Influenced $1.1 Trillion http://www.gartner.com/newsroom/id/2303215

2 Nautilus-PM Project Management method incorporating CPM www.nautilus-pm.eu

3 PMI Agile Certified Practitioner (PMI-ACP)®, http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx

4 UK Parliament, Defence Acquisition, Chris Donnelly, Session 2012-2013 http://www.publications.parliament.uk/pa/cm201213/cmselect/cmdfence/writev/acquisition/m15.htm

5 Checkland, Peter B. Systems Thinking, Systems Practice, John Wiley & Sons Ltd. 1981, 1998. ISBN 0-471-98606-2

6 Example of roadmap for traditional Enterprise Architecture: http://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html

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.

Evolution of a career ...

My career started in the true meaning of the word - I found myself careering like a go-cart out of control downhill. It is said that "necessity is the mother of invention"; this applied to my mindset as a teenager faced with the reality that as soon as I left school my bags and my person would be out on the streets and I would have to find my own way in life. I blundered through A levels, not quite sure where I was going. Like many young people, there would be a command from on high with instructions on "the types of career that would be acceptable", however, if one is not destined or does not have the aptitude, one is rather stuck.

We didn't have the Internet, nor Job Boards, we had the Unemployment Office of the DHSS. As a teenager these places looked daunting, impossible, so I turned to newspapers. They actually had real job there, but they were few and far betweeh.
In a flash of inspiration I took to the Yellow Pages, that is where we would look if we were looking to find anything, so the job hunting started with the first section, under "A".
Accounting - not for me, couldn't see myself just doing sums, Apothecary, no...
Banking - a distinct possibility so I sent out a whole flock of letters to various banks and lo and behold, I landed a job.

I was totally unprepared for the British mysogenistic banking world of the 1980s where I witnessed highly qualified and talented women being passed over in favour of men with the brains and charm of a monkey. It came to a crossroads and I decided to change tack purely by chance into insurance where I found underwriting and dealing with claims highly entertaining and ended up with my own department looking after marine, engineering, commercial property with small business risks.

However, the systems we used were suboptimal, any data entry was laborious and I soon had the idea that I would like to change the business processes and the systems. There was a wave of change going through the banking and financial sectors where back office work was being automated, jobs were moving from the banking floor to IT systems. There was an opportunity to embrace the technical side of business systems, which was just fascinating.

My own path was changed irrevocably with the advent of three children, who became fellow travellers on the journey through college and university to study information technology and business information, they even accompanied me to my lectures in Strategic Management. I thought they were all naturals. Still, they all have their own university degrees and are playing their own role in their own stories.

The first job I found was by pure chance, I happened to be shopping and happened to have a briefcase, a freshly printed CV and gaggle of kids when I spotted a poster that Hyder was hiring. I managed to sell the idea to a recruiter that they needed an IT and Business hybrid graduate and was invited to an interview for a Business Analyst. Now I thought that meant Financial analysis, but it was the analysis of systems and development of a coprorate business process model and information model using ERwin and BPwin, which were the beginnings of an Enterprise Architecture. Later Popkin built their System Architect modelling software with ERwin and BPwin at the core. Even the IDEF modelling was embedded.

What is hard is the uncertainty of it all, when you are trying to raise a bunch of otters who don't really understand why their mother is preoccupied still with reading new methods, techniques and playing around with interactive and collaborative software. To be honest, without a partner the children would have greatly suffered and worse still, they didn't understand, in fact I doubt that they understand what life would have been like without a dad.

The UK is no place to be a single parent. Europe offered far greater opportunities since as a mother you are not treated any differently from all the other workers. We all, men and women, were parents, partners, sons, daughters and all had equal role in family life. The work life balance was extremely important and as such, it meant that people made solid decisions that were taken calmly, deliberately and with consensus.

The Anglo-American work environment would do well to learn lessons from these more efficient and effective models. It is well documented that longer hours do not improve productivity, in fact, the contrary. As a mother, balancing the needs of family and the imperative need to deliver.  There is, nevertheless, an over riding tendency to over compensate, probably down to a perception that so much effort is put into children that work also requires an equal if not more attention, especially to delivery. The plus side, I've never had a pub or bar to support.

I have wondered if my partner, long suffering as he is, would expect to perform as much as I do as a professional and carry so much of the domesticities on top of this, but I have plenty of male counterparts who also do their equal share.

Maybe it is our industry, but I thank the Lord that I'm not expected to go to work caked in make up the way I watched the manikins totter into the banks in the 1980s. That was gruesome. I would say that IT is one of the best industries for women, we need more of them to take up systems engineering and come and join us. The greater the diversity of background, race, sex, age, orientation the better, we all bring something different, a new perspective to our work and collaboration.