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