Enterprise architecture development and strategic planning part 3 by Adrian Grigoriu

Enterprise Architecture Development and Strategic Planning Part 3 Customised for Date: By Adrian Grigoriu

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

Contents, i Part 1 1) Goal, Scope and Audience

2) The Enterprise problem and the solution 3) The Enterprise Architecture (EA) definition 4) Enterprise Architecture Drivers, Benefits, Business Case, Return on EA

5) Technologies supporting the EA 6) EA frameworks and their Classification 7) The EA framework definition and specification

8) Information, Security Architectures and other Enterprise Views 9) Enterprise Reference Maps and Organization design 10) EA patterns and Single Page Architecture Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

Contents, ii Part 2 11) EA framework cube and navigation tree

12) Mapping to Zachman and other frameworks 13) The Enterprise Wide IT Architecture 14) Service Oriented architecture - SOA

15) Strategic Planning: EA alignment to Business Strategy 16) EA development Best Practices 17) An EA development exercise (facilitated practical session)

18) Using the EA framework for outsourcing, M&A â&#x20AC;Ś 19) EA tools Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

Contents, iii Part 3 20) EA governance, program and site

21) EA maturity, value and sell 22) EA roadblocks, culture and politics 23) Current and future outlook 24) The Virtual Enterprise 25) Enterprise Architecture recap

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

EA Governance, Program and Site

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

EA will require 

Introduce EA controls in business processes – The Architecture Framework templates and principles should be incorporated as “controls” and templates into processes for reference and guidance in all future developments

– The Product/Capability development process will observe enforcement checks at each milestone against the architecture deliveries templates 

An Architecture control team should check all – developments are compatible with the Enterprise Architecture its and Framework – new solutions architecture is validated against the overall EA – new technology is validated against the EA technology guidelines



A catalogue of SOA business services should be created in repository for re-use Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA day to day operation 

Domains will use the EA framework: – design their own architectures within subsystem boundaries – provide same system views – interconnect their architecture at reference points in the framework – observe common architectural principles in the design process – use common convention, notations and tool



Suppliers will be distributed a reference architecture for their products



The Organisation of the Enterprise updated to ensure ownership of the Enterprise Functions by Business teams – A governance structure should be instituted to own the SOA services



The documentation updated continuously with the change submitted for Flows

Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA introduction 

The EA should be used across the entire company to support learning, making decisions and investments, designing new products and capabilities and do strategic planning.



EA compliance checkpoints and templates should be incorporated into all relevant business and IT processes:



The Product/Capability development process will observe enforcement checks at each milestone



Projects will have milestones checked against the EA deliveries templates.



Roadmapping process aligned to EA



the Investment process to consider the Enterprise Project Portfolio and technology selection to EA technical standards Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu © 2007-9

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA introduction i 

Departments shall: – design their own architectures using the same tools and conventions – provide architectural Views to the overall Enterprise Architecture – interconnect their architectures at reference points agreed with the EA – observe common architectural principles and technology standards in design



Suppliers should be distributed a version of the EA architecture so that they may include the required functionality, interfaces, protocols, roadmap and EA

technical standards in products. 

The Business improvement activity should be devised to take into consideration: process, technology and people performance at the same time.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA Governance EA Governance EA Governance Council: Business Sponsor, CIO, Chief Architect, Program Manager

EA Chief Architect

EA Program Manager & PMO

EA Tool/Site Lead Architects: Business Administrators EA Architect Applications EA Architect Technology EA Architect Information

Compliance& Maturity

Domain experts

EA workstreams Lead Architects

Solution Architects

Domain experts Portal, Cnt Mng, Id Mng, BI/SW)

Virtual team members Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

SOA governance 

EA should provide mixed business-IT governance, compliance, program management, administration teams and Enterprise Architects to lead the EA workstreams and supervise the key EA domains of activity.



The business and IT governance should be adapted to the new SOA structure, to enable ownership and operation of the business Services by common business and IT teams. A straightforward remedy would be that the people operating the technology would report directly to the business Function and in

dotted line to IT, to enable co-ordination with the rest of IT for technology standardization. A solution is to partition the IT department into units, reporting into broader LoBs, except for the few truly shared IT and EA central functions. The ultimate goal is to unify the business and IT teams and their objectives, inside the business Function.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA project or Business as Usual 

Is EA a project or Business As Usual (BAU) activity?



EA, ultimately delivers an asset, a capability



A project will deliver the EA in an 80/20 manner (functionality/effort). The project

should transit and deliver into a BAU team. 

The EA project should be organized in phases and staffed accordingly:

1. Planning phase: determine scope, iterations, resourcing and governance 2. Overall EA set-up phase – Architecture + program support group – Specify rather than choose the EA framework – Design the key EA layers and views

– Specify the vision state of the Enterprise Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA project, or Business as Usual i 3. Design and Implementation of iteration N – multiple teams/workstreams – Discover As-Is views – Design End and transition States – Plan, resource and Implement state for each workstream

4. GO TO 3 (after reviewing 1 and 2) 5. Form and handover to BAU team

The BAU EA team should follow the same design process with Solution projects. The main tasks of the team would be to coordinate the work done by Solution Architecture teams to assure fitness for the EA purpose Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA funding 

Initially, the development should be funded as a project with Operational Expenditure (OPEX) for development.



Both OPEX and Capital investment (CAPEX) are necessary for implementation but the CAPEX should be synchronized opportunistically with the lifecycle of existing technologies.



SOA requires that funding be distributed between the internal customers of a service. After the design phase, outsourcing of a service should be considered.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA program structure EA Program and BAU organization Program

Phase 1

Iteration 1 Workstream 1.1 Discover As-Is Design To-Be Implement Gap

Planning: Scope, Iterations, Governance Resourcing… Estimating costs

EA set-up: EA Framework, Principles, Standards, Strategies

Workstream 1.2 Discover As-Is Design To-Be Implement Gap

Workstream 1. 3 Discover As-Is Design To-Be Implement Gap

BAU transition

Iteration 2…

Workstream 2.1 Discover As-Is Design To-Be Implement Gap

Workstream 2.2 Discover As-Is Design To-Be Implement Gap

Solution Project 1

EA coordination Discover As-Is Design To-Be Implement Gap

Solution Project 2

EA core team EA core team

EA core + virtual team

IT Architects

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Enterprise Architect role 

The EA architect role requires putting together an EA business case to justify the EA development once and for all, then sell the EA to business and management to get sponsorship and resources.



Afterwards, the job demands the EA framework selection, customization and creative design since most frameworks stop at general architectural patterns like matrices, layered structures, triangles, pyramids, cubes, circular processes etc. This is a critical success factor for the rest of the EA development!



The architect establishes the design principles, the process, breaks down the EA work into workstreams, and organizes the teams to discover and document the current Enterprise state and blueprint.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Enterprise Architect role i 

Then he validates other Enterprise developments from an EA point of view: all solutions architecture designs have to comply to EA principles, standards and conventions, reuse the same components and link them to each other and the rest of EA artifacts.



Also, the ERP, SCM, CRM, MDM, Portal and business specific applications, suites and activities have to be properly documented at the process and technology layers, to be integrated in the overall EA.



Then the architect looks at the Business and IT Strategies - to align them to the Enterprise map and analyze their impacts - and determines the future state of the EA and its roadmap.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Enterprise Architect role and types 

A good number of Enterprise Architects (EAs) appear to come through the IT professional promotion ladder process which ends up at the top of this value chain: the Enterprise Architect. – They are veterans, they know people and people know them, they give advice and are knowledgeable about the company history, culture and motivation behind every technology in existence. They are often consulted by management and occupy a position of respect since some are legends for services rendered. Do they really do Enterprise Architecture? They mostly don't. They do check consistency of designs between projects and against their own experience, but they do not have a reference Enterprise Architecture to validate results against.



Another type of Enterprise Architect is the Integration architect; it is an important role since most applications are hard to interconnect even today. – They are chosen from the SOA ranks, as the middle name for SOA is integration for most adopters. Services.

Flows

Function O

Lines/Products

Process Technology People

Layers Planes

The Enterprise Architect types 

The Enterprise JAVA Architects so called because of the “Enterprise” in the Java EE naming. – The technology is said to be Enterprise wide, in that it may support all Enterprise applications.



Enterprise Solution Architects because they work in capability delivery projects. – They do patching and interconnection work to keep the applications running. This is not really EA work., but Solution Architecture.



The Enterprise IT strategist role, is the Enterprise Architect working on the IT roadmap which is aligned to the Enterprise Architecture. – If not based on EA, this role will deliver best effort silo-ed outcomes. leaving gaps which, later on, would demand resources competing with the strategy activities. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Enterprise Architect types i 

The Enterprise Architects are often classified in Applications and Infrastructure architects to enable work division and specialization. – Often they end up doing inventories of technologies and applications, working on these EA layers in isolation.



The Enterprise Data Architect and Warehouse roles are also created – when the Enterprise has trouble with managing its customer data or extracting reliable intelligence from available sources, which is quite often, simply because information is duplicated in many applications.



Business Architect roles are seldom if ever advertised – Business Architects occupy business analyst roles, mostly belonging to the "business" community; they have the task to look into requirements and model the business processes but typically out of the Enterprise Architecture context. – .

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Enterprise Architect types ii 

Hence, while there are "Enterprise Architects" in place doing IT solutions, integration, inventories... more often than not, there is no one to do the business architecture (business functional decomposition, process , business services).



EA architects do not really do EA framework design and customization, metamodel specification, EA compliance or maturity evaluation work. Since they are senior and experienced people, there is no way one can substitute them



One still needs to bring in "true" EA architects to develop and manage the EA.



An EA architect must be able to develop the EA framework, understand the business theory and practice and manage the EA development. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Business Architect 

The problem with the EA is that Enterprise Architects do not cover business architecture and business analysts do not cover technology, information or even architecture as a discipline. The division between business and IT does the rest of the damage.



In reality, one may not employ another team of Enterprise Architects. How would one avoid the conflict of naming and interests? Who is supposed to draw and drive the Enterprise Architecture? Does one have to reassign roles and

responsibilities or change titles? The risk is the loss of these valuable people. 

A solution would be to introduce the Business Architect role whose responsibilities are not covered by either current Enterprise Architects or

business analysts. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Business Architect i 

The business architect is not a mere business analyst.



The role, once created and properly filled, could take charge of the EA development since the business architecture drives the technology, describes the operation and goals of the company and conveys understanding to everyone in business and technology alike.



This role should be a senior one, unlike the Enterprise Architect today; it should have authority to suggest organization alignment, perform project and team management, resource, delegate...

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Business Architect ii 

To inspire trust to the top management, the role should be knowledgeable in



business operation, value chain analysis, supply chain, business models, Six/Lean Sigma, strategy and BPM



have an understanding of IT and architecture.



The Business Architect would lead the design of the Business Functions Map, Single Page Architecture, Business Flow Map, Business and Operating model

assessment, strategy alignment and so on. 

The existing EA IT architects would continue to do the IT work, play the same important role in IT, in alignment with the Business Architecture this time. They should have a dotted line reporting relationship to the Business Architect lead. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

How to select an EA architect 

Since there are few distinctive qualifications or selection criteria for an Enterprise Architect, how do you recognize an Enterprise Architect?



Most EAs have studied TOGAF, Zachman, FEA and quickly gave up on DoDAF. These appear to be the universal requirements for an Enterprise Architect.



Zachman is quite straightforward to read and understand.



All have browsed TOGAF, hard to go through due to its richness.



FEA is a simple framework (consisting of performance,... business, services, technology reference layers)



DODAF formalizes descriptions in diagrams types with relationships described

by a metamodel. It has its own vocabulary that departs a bit too much from the EA accepted modeling. Hence it is hardly usable, except in defense. Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu © 2007-9

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

How to select an EA architect i 

But this is not too distinctive since most IT architects can claim this.



The EA (SOA too) certification courses, do they help?



EA certification attempts to fill the gap to an experienced IT professional but,

typically, it does rely on the existing frameworks to guide the development work. 

The IT layers (applications, information, technology) are more often than not, presented extensively in training and certification courses. You will see long

chapters about network, DB, servers technologies, type of applications etc. 

But do they arm the Enterprise Architect with a practical framework to design or lead the implementation of an Enterprise Architecture? An Enterprise Architect needs to understand the framework connecting the layers and its navigation, rather than all layers in detail.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA architect tick boxes 

Since it is not too hard to tick the boxes for an Enterprise Architecture ad, the Enterprise Architect's curriculum must be usually backed by a long IT experience, references and social skills. There are also technology requirements: such as experience with Java, DBs, ERP... And the experience in the specific business domain such as "Insurance" industry.



Counting these criteria, is it possible to narrow down the candidates to a short list? Not by much.



The professional history, Zachman and TOGAF tick boxes, soft skills, technology skills like Java decimate the number of candidates. Ultimately a reference and the experience in the domain of business do the trick for most

jobs. You just selected an Enterprise Architect. But will you get an Enterprise Architecture?

Flows

Layers

D S

Function O

Lines/Products

Process Technology People

Planes

What an Architect looks like and EA consultancies 

These criteria help but unfortunately they may eliminate the "real" Enterprise Architects. But what is that? Someone who had a structured mind and takes the time and the pain to understand how things fit together. Might also have done hardware design since this is a more structured domain based on functionality encapsulated in chips.



Consultancies, do they have EA frameworks? They have variations of the existing ones. Consultancies count on the collective consultant experience to

resolve issues. 

For a consultancy, a typical framework - which changes quite often - is based on the known layers (business, information, applications, technology etc)

conveniently surrounded by a few great Zachman style questions, such as Why, Who, When, Where.... Orthogonally one will always find a security slice.

Flows

Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA’s architecture skills 

architecture know how: definition, principles, Integration experience



IT architecture styles (centralized, layered, multi-tiered client server, web)



IT architecture patterns and typical components: Content Management,

Presentation, Business Orchestration, ID Mng, B2B… 

SW and HW development experience at flowchart level



concepts as MDA (Model Driven Architecture), MVC (Model View Controller)



OO concepts, design and Distributed Components history (RPC, CORBA, COM)



UML modeling: context diagrams, Use Cases, activity, sequence, state diagrams, data modeling, ERD (Entity relationships), Class diagrams, BPEL



a disposition to draw diagrams and flowcharts before coding and soldering

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA’s architecture skills i 

EA Frameworks: Zachman, TOGAF, DoDAF, FEAF, TEAF…, PERA, NGOSS



SOA, ITIL, COBIT IT process and governance frameworks



Systems and Software Architecture and Principles

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA’s business skills 

Business acumen: operation of an Enterprise, Porter's Value Chain, Business Models, Operating Models, Governance, Financial Management, Performance and Cost Management, SWOT analysis, SCOR and VRM reference models



Business Strategy, Roadmapping



Business Process modeling (BPM, IDEF representations, swimlanes), Business Process Management, Business Orchestration and Rules, Balanced Score Card, Six Sigma, CMM, Change Management



A working knowledge of the specific business: products and stakeholders

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA’s technology skills 

Service Oriented Architecture concepts and Web Services protocols



Mainframe, client server technologies, databases, Content Management, Data Warehouse, Business Intelligence, reporting, B2B, Portal, Internet and IP technology, virtualization technologies, trends



Infrastructure: servers, storage, networks, telecommunications, OSI



Agile Processes, project management



ERP, CRM, SCM… applications suites



SDLC: Software Development Life Cycle



EAI/ESB distributed component architectures



Web Services, Java and .Net aware

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA’s social skills 

Able to communicate, influence, negotiate, motivate, facilitate and inspire, in other words, get the human interaction right.



Able to guide the EA development process and get support from all levels.



The Enterprise Architect should be politically savvy, able to present and argue at all levels of management.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Tasks the Enterprise Architect 

Prepares business case, exposes benefits and drivers



Specifies framework, best practices and tools



Establishes architecture, design and technology principles and guidelines



Supervises EA design and development



Coordinates works done by domain architects



Controls artifacts consistency and compliancy



Owns the EA repository and decides access rights



Presents, justifies communicates to all stakeholders in business and IT

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Tasks the Enterprise Architect i 

Recommends transformation roadmap and works with PM



Controls EA iterations and operation



Establishes compliance checkpoints in major development processes



Assesses EA maturity



Measures returned value

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The Tasks and Authority of the Enterprise Architect 

Recommends transformation roadmap and works with PM



Controls EA iterations and operation



Establishes compliance checkpoints in major development processes



Assesses EA maturity



Measures returned value

Authority 

makes decisions with regard to artifacts design and implementation



drives the virtual team of function architects



resolves architecture disputes Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Enterprise Architect’s leadership 

The Enterprise Architect as a leader in the transformation of the Enterprise and a participant in the business decision making process. (Right now, this is not the case but the trend points in that direction).



But what is a leader or leadership? And what is it compared to management? – Management is about organization, control, planning and budgeting. – Leadership is about motivation, mobilization, creating the vision and establishing the culture and relationships.



To succeed, an Enterprise Architect has to act as a leader to motivate people, mobilize resources and create the EA vision while as a manager has to manage the complexity of the Enterprise Architecture development, documentation and day to day running. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Enterprise Architect’s leadership i 

Latest thinking points out that leaders must have theatrical qualities – theater is in fact another term for excellent communication skills, the ability to hold an inspiring speech in front of people at a function.



It is possible to have a leading position without having leadership capabilities or the other way around.



A leader is an individual who leads a group's activity to a specific purpose. But these individuals could be selected, nominated, self-nominated or inherit a leading position, a position of authority.



Leadership is the quality of an individual to attract followers for a purpose. – A leader must inspire trust and respect, coming from natural personal qualities, experience and education. – Leadership requires self confidence and emotional control to reassure and inspire the followers. 38 Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu © 2007-9

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The qualities of leadership 

Inspiring trust and respect is vital, even if the leader has a position of power, but how is it done? – be credible and lead by example. This requires top competence in that field of activity, a basic sine qua non condition for the leader.

– Self confidence has to be rooted in knowledge and experience rather than mandated by culture (you must be confident at all costs!) or two days training courses. – The leader would find solutions where few can, strengthening the others' confidence. – He is Not someone who is looking the part, confident, decided, sure of success but without with the depth to deliver. The problem is that without the underlying professional ability, the confidence is wrong footed and the results average.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The actor’s leadership 

The surrogate leader fails without knowing why, since he is playing the role well and moreover believes unconditionally in himself.



Acting the role alone, will not deliver professional results. Acting the role of a leader, can only benefit, in the long term, the actor, the "leader" and not the group.



There is a difference between the role and the reality, the personage and the person. An actor is at his best when plays naturally since he is authentic i.e. a leader. – Otherwise there is a mismatch between substance and form, easily noticed unconsciously, decoded by primitive but efficient detectors within ourselves: the eyes which do not smile or avoid looking into your eyes, the gesture that does not confirm the words, the intonation gone the other way. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The leader should have 

Leadership needs authenticity to succeed, that is, the image shown should fit the substance and competence. Authenticity means "you do what you say" and "you say what you think".



The leader should have a vision, an ideal that inspires people and determines them to follow in the long term.



He does the "right things", and does "things right" as a good manager/ administrator does.



He should be emotionally stable, having a degree of Emotional Intelligence (EQ as opposed to IQ), so that he could understand, interpret and control emotion in others. But the leader is in control of himself first.



A leader should be passionate to inspire his followers with his energy and

Flows Layers

D S

enthusiasm.

Function O

Lines/Products

Process Technology People

Planes

Leadership archetypes 

There are archetypes, or worse, stereotypes of leadership. The hero leader in films is a typical example. – People are molding themselves on heroes since early childhood. We struggle to imitate the best, their behavior, we learn from them. There is also the stereotype of the business manager played by many, unfortunately.



In a culture driven by acting leaders, the real work would not be prized any longer; meritocracy would be applied in terms of acting skills.



An acting leader can empower, delegate, but the immediate ranks feel the competence void. This leadership will be maintained not by respect inspired by competence but through power, minute control and politics.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Leadership depends on field 

The style of leadership depends on field: – a warrior leader would be bold and ready to fight, – a president would be a decision maker – a conductor would orchestrate the individuals in the orchestra. This would require different qualities.



Leadership also depends on situation such as a company in difficult times



There are evil leaders. It does not necessarily mean doing moral "good". – Why people follow them? Because trust, belief and the lack of doubt is said to make people content, if not happy. It was discovered that following is easier than leading, that too many choices or decisions make people unhappy.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Leadership and EA 

In normal times leadership is welcome but not in demand.



Leadership comes from will or desire to lead, since it is not solely a blessing but a very consuming activity, requiring sacrifice and dedication to the cause.



EA is a difficult task. Many people in management, business and IT would have to trust the Enterprise Architect and take action. But without the right authority the task is made impossible for the Enterprise Architect.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The growth of EA jobs ď ą

The good news is that there is an increasing demand for EA jobs ( UK survey)

The chart provides the 3-month moving total of permanent IT jobs citing Enterprise Architecture within the UK as a proportion of the total demand within the Processes & Methodologies category. [i] http://ww.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?s=enterprise+architecture&l=uk

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA maturity, value and sell

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

EA Maturity 

The Capability Maturity Model of Carnegie Mellon Software Engineering Institute (SEI) is a main source of inspiration.



The development maturity model assesses the phase of EA development.



The exploitation model determines the degree of adoption.



An important factor is overlooked deliberately at this stage. the quality of EA. – This depends very much on EA definition, scope, framework (and artifacts) and practical purpose of development.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA Development Maturity evaluation i 

Phase 0: Pre-EA From value not assessed or understood until EA Business Case is approved. There is no commitment or capability to plan, design or execute.



Phase 1: EA Program Definition Until the EA organisation is set up, planning and resources are approved and committed, Chief EA Architect, PMO & Steering Committee agreed. Capability to design and execute exist or planned.



Phase 2: EA Design Until a Framework and tool are selected, As-Is Architecture is discovered, intermediate stages and To-Be sketched, Transformation Plan approved and KPIs, CSFs, quick wins… determined. EA documented.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA Development Maturity evaluation ii 

Phase 3: Transformation Plan Execution, on-going Implementation and next iteration detailed design and then execution; until the EA Transformation program delivers 80/20 (functionality/effort) and EA value is achieved and measured. Enters partial exploitation phase.



Phase 4: EA delivered 80/20 delivered. Enter now the full exploitation, while small incremental stages still deliver. CMM used now to assess maturity of the EA utilisation and maintenance process.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA Exploitation Process Maturity i 

Level 0: EA ignored Though EA artifacts exist they are ignored or not easily available. No EA handling documentation, no ownership.



Level 1: Empirical EA exploitation By a few stakeholders, the process is repeatable but depends on people; there is ownership but the usage process not clearly documented.



Level 2: Documented EA usage process

Clear ownership for stakeholders; the exploitation process is well defined.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA Exploitation Process Maturity ii



Level 3: Managed EA Exploitation process embeds active controls and audit points in Enterprise processes; there is on-going EA improvement and maintenance. Used by management, business and technology to control investment, enable decision making and managing change.



Level 4: Optimising EA



EA is used in product design and organization evolution by embedding strategy in the EA transformation roadmap.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Measuring the Value of EA 

The better the architecture, the better the outcome, i.e. the returned value.



A good architecture structure reduces duplications and overlays in processes, platforms, projects and sometimes people and it consolidates the many interconnections.



A good EA framework – describes the structure, standardizes best practices and technologies, – maps strategies on architecture components and architecture layers such as processes to people and technology. – It makes understanding the operation and training people easy.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA Value and Business Case benefits 

The Enterprise Architecture delivers value, as soon as it is designed and implemented. – it does that, gradually, while it is implemented by increasing the effectiveness and efficiency of your Enterprise.

– EA soon becomes an asset in its own, returning value to your Enterprise. 

A project justification is done at Business Case time, before the start of the development, – by enumerating and estimating a number of key benefits. – these initial benefits should be tracked and measured at implementation time to prove the delivery of promises. Same applies to EA.



The EA scope is key though, since more scope should return more value. – EA iterations may add scope and as such, new value. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Measuring the Value of EA in scope 

But EA definitions vary and their scope is wildly different for each development. – Is it an IT only architecture? Then you are looking only at the benefits of standardizing technology and integrating applications. – With business and people architecture the picture changes significantly. The Business, Organization and IT alignment with ensuing benefits can only be achieved if you include in scope a Business Architecture.



Once the scope and deliverables are established, the benefits and business case of the development can be estimated.



The EA success should be measured against the listed benefits and deliverables in scope rather than against an abstract EA that does not have an agreed definition, but promises a lot, in vague terms. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Measuring the Value of EA against the Benefits table 

A table of key business improvement benefits, the way to measure them, and their stakeholders should be defined from the beginning and measured at the end of an EA iteration.



The key benefit indicators may be grouped in a few categories: – Operational (those enhancing the operation such as single customer view master data management -, Development (improving your innovation and the new product development process, reflected in time to market) and Support (enabling single version of truth for reporting…) – Governance (enabling understanding, communication and decision making in the organization) – Strategic, enabling effective execution of strategy – Communications and Collaboration Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Measuring the Value of EA against the Benefits table 

The EA development success is measured at implementation time with project progress indicators.



An EA maturity framework will help you measure progress in the development and compliance in exploitation phases;



It will do that by measuring success from a process maturity and extent of business participation points of view rather than from a business value view.



A Balanced Scorecard approach for performance measurement and management of your Enterprise is supported by the FFLV framework in that it is addressing the four scorecard views: market (customers), processes (company), learning and growth (people) and financials (owners). Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Evaluating EA architect’s performance 

How do I justify my job as an EA architect!



Many "EA architects" are not really doing an EA design work.



One can evaluate your EA job performance by assessing, after each iteration,

the benefits stated in the business case and measured by key improvement indicators in the benefits table. 

This could be correlated with a maturity framework evaluating the EA

development progress, participation and compliance to EA.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Sell the EA 

One of the issues continually confronting us in the EA arena. To sell it, start by identifying the interested and affected parties for each iteration, the stakeholders.



Ask the old question "what's in it for them?" and "what is the impact on them" since they would be asked to support, pay or even contribute to it!



The potential audience depends entirely on the scope of your EA development which can vary a lot. Is your EA an IT only architecture? – If you define your architecture in terms of applications, information and technology architecture you address an audience in IT, for the most part. – For IT, do you intend to include content management, knowledge management, BI, DW, integration architectures? That will enlarge your IT audience. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Sell the EA to top Management and Support 

To satisfy the interests of most potential stakeholders, the concept of architectural view is crucial: – a view satisfies the concerns or needs of a stakeholder group. There are as many views as stakeholder types.



Top management, what is in it for them? – The representation of the Enterprise governance, the roles and responsibilities, governance bodies and principles of decision making, – the business models - how the business makes a profit -, – strategy alignment to the Enterprise organization, – regulatory compliance and not least a business blueprint.



For Enterprise shared services organization: – support functions as HR, Payroll, have to be described in terms of services, processes, costs and effectiveness. Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu © 2007-9

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Sell the EA to business 

information on IT or other technologies in use – – like SCADA and GIS for utility companies – process automation and improvement, – business rules and orchestration – reporting and Business Intelligence blueprints.

If you provide this information the business organization would become your supporter.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Sell the EA summary 

Put together, upfront, an EA drivers and benefits pack and a business case based on financial terms.



Business management thinks in terms of Payback, ROI, NPV which are measures of profit vs costs, typically applied to projects.



A table of benefits, such as time to market, agility, and the estimated EA contribution to them at each EA iteration will do a lot of good to the sales process of EA.



Calculate RoEA at each iteration.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Sell the EA takeaway 

The EA has to be opportunistic, planned to deliver first what the business needs such as a Single Customer View or a Single Version of Truth architecture.



A natural progression to EA with obsolete systems and technologies replaced when their time has come and not before would reinforce the EA sell effort.



Business does not see technology in isolation as IT does, except as a source of problems.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA roadblocks, culture and politics

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

EA triggers 

An imminent Merger and Acquisition, the amalgamation of two companies



A decision to outsource Functions



Establishing a new company



Technology infrastructure needs urgent alignment to business Strategy



Imminent regulatory issues



The company suffers from inefficient processes;



A re-organisation to adopt a new business model is on the agenda



Master Data Management or Customer Data Integration initiatives



There is an acute need to upgrade from obsolete technology as Mainframes Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA triggers, trends

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Function O

Lines/Products

Process Technology People

Planes

EA roadblocks, what are they? 

But what are the factors hindering the adoption of EA and its success? Moreover, how can we overcome them?



Enterprise Architecture “roadblocks” or "inhibitors" are factors and approaches to the EA design, implementation and exploitation which limit the number of

stakeholders and do not promote further usage



By exploring “roadblocks", EA development obstructions would be better understood and eventually neutralised

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

“Nothing will be ever achieved if all objections must be overcome first”

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA positioning on Gartner’s hype cycle •Gartner’s Hype Cycles characterise the overenthusiasm or "hype" and subsequent disappointment that typically occurs with the introduction of new technologies. Hype Cycles also show how and when technologies move beyond the hype, offer practical benefits and become widely accepted.

Hype

Market Maturity Technology

Peak of Inflated

Trough of

Trigger

Expectations

Disillusionment

Slope of Enlightenment or Fade Away

Plateau of Productivity

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Outline I.

Current state of the Enterprise

II.

Vague EA definition and scope

III.

Uncertain Return Of Investment

IV.

Diversity and verbosity of EA frameworks, lack of agreement

Politics and design outcomes not fit for purpose

VI.

Ambiguity and competition with other EA technologies, SOA, ITIL ERP

VII.

Effort governed by IT alone

VIII.

Flawed Enterprise transformation planning and execution

IX.

Improper EA maintenance and failure to employ proper tools

Recap

Flows Layers

D S

Enterprise Architecture roadblocks and how to overcome them Copyright Adrian Grigoriu ÂŠ 2007

Function O

Lines/Products

Process Technology People

Planes

The current state of the Enterprise



Cultural inertia – EA challenges the status quo



Predominant tactical thinking – EA means strategic planning



Silo organization – where politics already exist

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The current state of the Enterprise



The existing divide between Business and IT



Lack of a reference business architecture (exceptions: NGOSS, SCOR)



Enterprise Architecture and SOA over-hype

 The Enterprise Architecture is the “cure”

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA definition, is it …? At EA specification time, the debate is about the meaning & scope of EA 

Is it an Enterprise IT integration program?



Is it Business Process Management (BPM) development?



Is it an organization alignment to strategy and business objectives?



Is it … – an Enterprise state – a document – a process

– a program – an organization design – strategic planning and Enterprise portfolio management?

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA definition from CIO “An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.

Purported advantages of having an enterprise architecture include improved decision making, improved adaptability to changing demands or market conditions, elimination of inefficient and redundant processes, optimization of the use of organizational assets, and minimization of employee turnover.”

SearchCIO.com - CIO Definitions, June 8, 2005. Posted October 13, 2006.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA definition from GAO General Accountability Office (GAO) of the US federal government "An enterprise architecture is a blueprint for organizational change defined in models [using words, graphics, and other depictions] that describe (in both business and technology terms) how it operates today and how it intends to

operate in the future; it also includes a plan for transitioning to this future state“. 

Enterprise Architecture: Leadership Remains Key To Establishing And Leveraging Architectures for Organizational Transformation, GAO-06-831, August 2006 http://www.gao.gov/new.items/d06831.pdf

But there are other definitions

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA definitions from FEA and TOGAF 

“The FEA (Federal Enterprise Architecture) consists of a set of interrelated "reference models" designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of the FEA in a common and consistent way. Through the use of this common framework and vocabulary, IT portfolios can be better managed and leveraged across the federal

government.” 

An EA defines the components or building blocks that make up the overall Enterprise “their interrelationships and guidelines governing their design and evolution” TOGAF 8.1 FAQ Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA definition, a FAQ perspective



What: is the structure of an Enterprise and its blueprint describing:



How:

the operation & processes of the Enterprise executed by



Who:

the people performing processes



Which: and the technology implementing them



Why:



When: according to the plan for the Enterprise evolution to a target state



Where: showing the location of people and technology

to streamline, align, blueprint, plan strategically and bestow agility

The EA ultimately constitutes the Enterprise Knowledge DB

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The EA artifacts are … the Enterprise structure and the operation blueprint describing the current, future states and transition plan in artifacts such as: 

Business Architecture – Products, Value Chain, business model, stakeholders’ use cases, strategy – Business processes, rules, orchestration, B2B choreography



Technology & IT Architecture



People & Organization architecture



Information and other architecture views: location, planning, security…



The Enterprise transformation roadmap and its project portfolio all mapped and linked through an EA framework

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

And the EA is



The structure and operation of an Enterprise,



the blueprint of its business processes, technology, people and organisation,



the EA development process, strategic roadmap and transformation plan are all part of the same answer, the Enterprise Architecture; but EA is more:



All non-IT technologies, Disaster Recovery, facilities/real estate, fleet...

 and it is more than the sum of its parts  it is about the governance (mind) and the culture (soul) of the Enterprise (body)

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA scope typically covering only IT



The scope dispute hits the balance between the tactical & strategic thinking



The benefits diminish at the same rate with the scope reduction



EA architecture is often narrowed to IT solely – Enterprise Wide IT Architecture (EWITA) or

– Expressing the IT department operation (itSM/ITIL) – Business process map, sometimes only

 reduced to IT, the EA fails to involve business & management  to live to expectations, EA should represent more than IT Architecture

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA IT scope not addressing many IT concerns



seldom covers other IT architecture views (typically the main product view): – No Knowledge or Content Management, Data Warehouse, Business Intelligence… – Often no email, printing, voice, network, SOE, Helpdesk… architecture views – Information architecture? Now and then

 EA needs a wider scope to include other architecture views to provide motivation for all IT teams  Enterprise IT Architecture is more than Applications and Infrastructure

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA scope not covering other technologies



Non-IT technologies uncared for (e.g. Real Time operation technologies – SCADA -, networks, utilities infrastructure, manufacturing bands, facilities…)

The IT only view is restricting the sphere of interest to just a few types of IT intensive enterprises and, inside a company, to a few stakeholders, reducing

adoption to a few classes of Enterprises

 For wider adoption EA has to cover all Enterprise technologies  Technology is more than IT

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA scope not addressing top business concerns 

Little relevance for Enterprise stakeholders such as owners, employees, community… – Except for the customer’s processes, there are seldom other views – Lack of links to the Enterprise Value Chain or business model



Many internal stakeholders’ interests are not addressed: – Finance, real estate, facilities, parking, fleet, internal post architecture



No relevance to the regulatory or support functions (HR)



EA may not address management concerns e.g. governance

 lack of management support which prevents funding and adoption  EA should address all business stakeholders’ concerns

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA scope usually over-simplified 

Reduced – To four layers: Business, Information, Applications, Infrastructure



No logical architecture –

to convey comprehension of the structure and operation of the Enterprise



Lack of the “architectural views” concept



Information architecture scope reduced to structured data – no document & knowledge management

 EA needs to include architectural views (concerns specific to stakeholders)

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA scope excludes people and organization 

Quite often business processes are executed by people not IT



But human performance not described since people are not in scope



People culture and communications also affect your Enterprise performance



Organization alignment to business strategy and process usually, the object of a separate initiative

 but the org chart should be aligned to your EA so that people take ownership of functions, processes and technology they execute  “The Company is the People" who govern, plan and operate the Enterprise

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Progress, so far I.

Current state of the Enterprise

II.

Vague EA definition and scope

III.

Uncertain Return Of Investment

IV.

Diversity and verbosity of EA frameworks, lack of agreement

Politics and design outcomes not fit for purpose

VI.

Ambiguity and competition with other EA technologies, SOA, ITIL ERP

VII.

Effort governed by IT alone

VIII.

Flawed Enterprise transformation planning and execution

IX.

Improper EA maintenance and failure to employ proper tools

Recap

Flows Layers

D S

Enterprise Architecture roadblocks and how to overcome them Copyright Adrian Grigoriu ÂŠ 2007

Function O

Lines/Products

Process Technology People

Planes

Uncertain Return of Investment At EA initiation time, the argument is about 

The hype which animates the IT but annoys the business



Drivers and benefits only subjectively expressed



“To Do or Not To Do” Enterprise Architecture debate – not supported by business case in financial terms: fails to rally support – and becomes perpetual

 The business case needs to assess costs and evaluate long terms benefits in financial terms the business can understand  Business Value returned should be evaluated after each iteration Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The best thing you can do is the right thing, the next thing you can do is the wrong thing and the worst thing you can do is nothing! TR

Flows Layers

D S

Enterprise Architecture roadblocks and how to overcome them Copyright Adrian Grigoriu ÂŠ 2007

Function O

Lines/Products

Process Technology People

Planes

Diversity and verbosity of EA frameworks (i) 

Diversity of approach, scope and purpose is hindering adoption



Some of the existing EA frameworks are, by and large, cognitive aids asking key questions such as why, what, how… (Zachman, E2AF)



A few handle implementation program management best practices (EAP)



Some describe reference models listing the outcomes and implementation guidelines to serve as reference for other EA developments (FEA)



A few approaches are confined to business process maps, ignoring IT



Some specialise on domains as government, defence (DoDAF), manufacturing, supply chain (SCOR), telecoms (NGOSS)…



Some of them consist of large, verbose documents

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Lack of an agreed EA framework 

Most frameworks leave out people and organization ("who") or some are narrowed down to business process architecture ("how") only



Some have been applied for a while with less than convincing results since are not taking the development too far or are obsolete and used no more



In other words, there is no consensus on approach or scope – How do we choose a framework?

– Are there any recommendations for framework selection? – Are frameworks enabling drawing the complete picture of the Enterprise? – Is the chosen EA framework fit for the purpose of your endeavour?

 You may still have to create your own framework, eventually as a combination of other frameworks Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Politics and design outcomes not fit for purpose



The Enterprise knowledge is locked in people's minds  The ability to extract information requires negotiation skills  Not consulting relevant groups breeds the “not invented here” syndrome



Design outcomes not fit for implementation – “tome” delivery for the politics of “passing the buck” to the next phase



Deliver diagrams, pictures Zachman: when you need it you will not have time to read

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Ambiguity to SOA, ITIL hinders EA adoption 

SOA is a business services development first and an IT integration technology second



While not an inhibitor as such, SOA harbours under its umbrella a development that should be covered by the EA process



SOA does not cover the discovery of existing architecture, technology alignment to strategy or organization design

 SOA should be part of a larger EA development since EA addresses the whole Enterprise development process



EA covers the whole Enterprise not only the IT department (e.g. ITIL)

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

ERP overlap, aiming to provide EA process & application layers 

ERP application suites, cover many Enterprise functions: planning…



Provide business processes embedded in the application layers



Historically, ERP application suites were successful as they reduced the hassle of integration of Enterprise applications from various vendors but – the Enterprise's agility is at stake from too tight integration – ERPs, covering EA space, remove attention & resources from EA

– proprietary ERPs hamper SOA best of breed solutions

 Employ ERP modelling (re-engineering) to re-use the existing ERP

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA governed by IT alone Initiated solely by IT 

EA has little chances to enrol business, support functions, other stakeholders and top management

 Business & IT governance, from the very beginning, for all phases –

To represent key business functions and IT, in scope of the iteration

–

Define EA governance principles

 Initiate a business architecture with business governance if no pre-existing business process map/reference architecture

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Flawed Enterprise transformation planning and execution 

Trailing for too long –

there is little tolerance for long programs with uncertain results



Not solving the immediate business pains



Failure to adopt the Enterprise transformation plan for execution

 Create the Enterprise project portfolio from transition roadmap  Prioritise current business and technology needs  Use an “agile” like process with frequent deliveries  Monitor progress, evaluate and advertise the value delivered at each iteration

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Improper EA maintenance 

Improper EA maintenance, at exploitation: make sure EA is not ignored, forgotten or becoming a dead weight by

 policing new solution development and integration work –

introducing a compliance watchdog from members of EA team

 instituting EA compliance –

controls (checkpoints) in all relevant business processes: technology selection, SDLC, business process improvement …

–

policies supporting the architecture decision making process

 providing a catalogue of existing and planned SOA services with clear ownership

 supplying internal training Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Failure to employ an EA tool 

Usually teams design EA artifacts, with various tools of choice and no common component repository; there are – component duplications and – no common notations, design principles or properties for components – no links for navigation between components and artifacts



Without a tool, maintenance of the EA is hard work – A change is hard to propagate to artifacts produced/stored by various tools – Poorly updated EA artifacts will satisfy users, no more – The artifacts are rapidly becoming obsolete and after that, seldom reused

 An EA tool based on a repository, working along an Enterprise knowledge management system, would ensure a long lasting EA Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

The EA knowledge handicap 

The difficulty to acquire and manage the vast knowledge required by an EA, spanning all business and technology domains – Enterprise Value Chains, Business Models and Strategy, Operations – Business Process Frameworks, BPM, Rules, orchestration, BAM, B2B – EA frameworks, architecture design methods, modelling and tools – IT Applications and Infrastructure, ITIL, DW/BI, MDM, Identity Management – Applications and suites - ERP, CRM, SCM, CM, KM, Portals… -

– SOA, Web Services – SOAP, UDDI, WSDL, ESB, Web2.0, JAVAEE, .NET – Change management, process maturity models, M&A, outsourcing-SaaS… – Organization design and Human Performance, governance, politics

 Select a quality, politically astute EA team, since it is a major risk Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Recap (i) To return benefits to expectations, an EA architecture needs to 

be unmistakably defined and scoped - for your specific initiative!



consider all stakeholders concerns: customer, owners, partners, employees, community... and not only the main product



address business concerns to have visibility and support from business and top management



cover the whole Enterprise operation rather than solely IT and all other technologies rather than IT alone



cover people/organization and align to business processes and technology



provide a business case in financial terms to avoid perpetual discussions

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Recap (ii) 

promote mixed business/IT governance at every stage since IT alone has no authority to – get traction from firm's management, business, stakeholders outside IT – drive the business architecture – influence corporate strategy, project portfolio and investment – recommend organisational changes



provide views besides the simplified 4 layers architecture – stakeholders' interaction, Value Chain and business model – logical structure of the Enterprise

– content & knowledge management architecture, MDM, DW/BI views – governance, financial/accounting, marketing processes, HR, fleet… views

Flows Layers

D S

100

Function O

Lines/Products

Process Technology People

Planes

Recap (iii) 

resolve ambiguousness with regard to other Enterprise related technologies – SOA is an architecture style and integration technology for the Target EA – ITIL is only the EA of the IT department – Existing ERPs should provide the applications and process layer of EA



observe potential roadblocks from the very start



prioritise business needs, deal with the EA trigger causes first



employ “agile” processes with frequent deliveries, wide consultations



employ an EA team having a vast knowledge of all Enterprise domains



use an EA tool linked to an Enterprise knowledge database



install architecture controls, check points in relevant business processes

Flows Layers

D S

101

Function O

Lines/Products

Process Technology People

Planes

Roadblocks review There are roadblocks at every step of the EA development process, from the 

current state of inertia and division in the Enterprise



EA poor definition and unclear scope



lack of an agreed EA framework



unproved business case



deceptive competition with EA other technologies



vast knowledge, EA team a risk, EA tool set required…



to implementation and exploitation faults



and lack of stakeholders’ support and thus politics

 The time is always right to do what is right! MLK

Flows Layers

D S

102

Function O

Lines/Products

Process Technology People

Planes

Bear in mind 

EA means: – streamlining, alignment, integration, blueprinting, agility & strategic planning

– reduces silos and crosses the division between business and IT 

SOA, is only part of an EA development consisting of – the style of the target architecture based on services – the integration technology



EA + SOA = Service Oriented Enterprise Architecture, a development crossing all Enterprise boundaries



EA requires commitment to strategic thinking – Failure to act on the Enterprise transformation roadmap is one of the chief ways to let down all your entire EA effort

Flows Layers

D S

103

Function O

Lines/Products

Process Technology People

Planes

Good Practice



Communicate to inform and get wide approval



Create an knowledge site, integrated to the EA tool, to document the EA and provide transparency to activities, budget spending – EA vocabulary and FAQ site for information and education – EA framework, principles, tool – EA team, contact points and governance – EA transformation plan & progress dashboard, decisions register on Intranet – EA checkpoints in Enterprise processes – And all EA Business, technology & organization artifacts (strategy, policies…)

Flows Layers

D S

104

Function O

Lines/Products

Process Technology People

Planes

The Enterprise Culture and EA

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

105

Function O

Lines/Products

Process Technology People

Planes

Enterprise Culture and EA



The Enterprise Architecture development has to be supported by the organization and its culture. – People are the company; they can make or break the EA. – To succeed one has to adapt the organization and subtly sniff and influence the culture.



SOA requires a new governance based on services. – People are accountable for the service they deliver, its roadmap, business, IT technology, usage, defects, service continuity and for acquiring internal or even external customers.

Flows Layers

D S

106

Function O

Lines/Products

Process Technology People

Planes

Definition of Culture 

- "The set of learned beliefs, attitudes, values and behavior that are characteristic of a particular social group or organization."



- "A set of shared norms and values which establish a sense of identity for those

who share them". 

- "The sum total of the ways of life of a people; includes norms, learned behavior patterns, attitudes, and artifacts; also involves traditions, habits or customs; how

people behave, feel and interact; the means by which they order and interpret the world; ways of perceiving, relating ...“

Flows Layers

D S

107

Function O

Lines/Products

Process Technology People

Planes

Own definition of Culture 

Company culture is a set of principles and values that drive the behavior of a group and shape the way people respond to events and get things done beyond established procedures.



It consists of, and is transmitted by rites (ceremonials), traditions (established ways of doing things), legends (heroes and deeds people treasure) and education (training).



It is reflected in the way people solve issues, communicate, celebrate, approach management (direct call/email, kick the door open…).

Flows Layers

D S

108

Function O

Lines/Products

Process Technology People

Planes

Culture is influenced by and determines 

It is the unwritten code of behavior in a firm; – it determines the attitude towards colleagues and work; – it lives in people's minds and hearts; – it is determined by the successes and history of the company; – it makes people proud, ready to identify with the company and set its interests first.



Culture becomes tradition.



The culture is the collective soul of the organization.



It is influenced by: type of governance, internal regulation, empowerment (liberty to act in some established limits), height of the organization tree (bureaucracy), clarity of accountabilities and roles, freedom of communication, right of opinion and recognition policies which make employees happy which in turn make the company successful.

Flows Layers

D S

109

Function O

Lines/Products

Process Technology People

Planes

Values and Culture 

Company values are the principles or rules of behavior which determine culture; – they have to be meaningful, realistic, even measurable - unlike the values of most companies, today – – It is important what happens if people ignore or even act against values.



An Ethics code, based on values, represents the code of law preserving the culture; – it has to be communicated and policed, because otherwise it becomes a "lip service" of, and for the powerful and the manipulator: insider trading, networking, nepotism begin to manifest until, like societies, the company begins to disintegrate.

Flows Layers

D S

110

Function O

Lines/Products

Process Technology People

Planes

Culture and Leaders 

God had created people in his own image, it is said. In a similar manner, a top Executive determines the culture in the organization through – personal example, – choice of direct reports - in his own image – of governance, – business strategy – ethics code.



Empty words won't do! – People, intuitively, have an 6th sense, the ability to feel the truth from gestures, expression, phrasing and intonation.

Flows Layers

D S

111

Function O

Lines/Products

Process Technology People

Planes

Known organization cultures 

- "Meritocracy" is the culture of reward and recognition associated with rapid progress and pride in the organization.



- The "can do" culture characterized by achievement, as opposed to the "can talk"

culture. 

- "Innovative" culture where invention is rewarded and praised



- "Agile" where formalism is replaced by people’s empowerment to immediately act



- "Blame culture" where if anything goes wrong a scapegoat is found; the consequence is that people rarely assume accountability



- "silo " where the departments don't care about the greater, collective good.



Some of these types can co-exist. Flows Layers

D S

112

Function O

Lines/Products

Process Technology People

Planes

Meritocracy and its merits 

The best culture is meritocracy that worked so well for societies. – Everyone achieves the position deserved in an organization with optimum results for the individual and the company. – It is the ideal win-win balance of benefits between the company and employees. – There is mutual respect (we respect achievers), and – everyone knows their own place (promoting the right individuals rather than self promotion). – Collaboration is the norm and people care for each other.



A good culture polarizes individual behaviors towards the company goals first (rather than personal gains) from which all other individual rewards come, proportionally.

Flows Layers

D S

113

Function O

Lines/Products

Process Technology People

Planes

Meritocracy and its merits 



A good culture polarizes individual behaviors towards the company goals first (rather than personal gains) from which all other individual rewards come, proportionally.

Flows Layers

D S

114

Function O

Lines/Products

Process Technology People

Planes

Introducing a good culture 

a history of success, conserved and taught



a code of ethics and values that are enforced



freedom of speech



transparency of decision making



clear governance, thin organization



fair participation and repartition of benefits (unlike the CEO/employee salary ratio today >> 50:1!)



empowerment, recognition and fair promotions

Flows Layers

D S

115

Function O

Lines/Products

Process Technology People

Planes

The wrong culture 

The wrong culture can ignore or make fruitless the EA efforts and for what it matters, can wreck the company.



In a difficult culture the personal interest comes first against the Enterprise. The

company sinks under the weight of the many individual benefits working against each other and the common company goals. 

Not only a firm, but a society falls apart under the weight of an incompetent or

corrupt administration fighting solely for power and personal benefits. The disease spreads quickly downwards, by example rather than discourse. 

If formal mechanisms are not set in place, culture tends to deteriorate with people tending to take advantage of the honest, the trustful, the weak or the unaware.



Action is necessary to enforce ethics, transparency, empowerment and recognition in support of a positive culture.

Flows

Layers

D S

116

Function O

Lines/Products

Process Technology People

Planes

How to change Culture 

That is, change it in a positive sense since it may often happen otherwise.



The cultural change starts at the top.



It requires honesty (as opposed to political spin), justification, communication, openness (information available to anyone concerned) that is, all in all, transparency (information available to anyone) enforced by a Freedom of Information like act.



Accountability (the ability to associate people’s performance to task accomplishment) and recognition of merit are essential to enforce a successful culture.

Flows Layers

D S

117

Function O

Lines/Products

Process Technology People

Planes

How to change Culture i 

Management at all levels has to pay attention to atmosphere and open communication channels so truth can be told with immunity.



Freedom of speech is key to evaluation of culture.



Personal performance evaluations have to be performed by customers and colleagues rather than managers alone who can spin the outcome from fear for their positions.



In times of hardship, un autocratic culture with a cult for a leader, may succeed though, like in time of war.



So cultural changes may be beneficial depending on existing conditions and the

place of the Enterprise in its lifecycle.

Flows Layers

D S

118

Function O

Lines/Products

Process Technology People

Planes

What works against Culture 

Practices like "networking" are clearly working against meritocracy since the best available are not selected. Positions are not advertised, only a few are in the know, and only a few can occupy the position in an exchange of favors.



These people team to maintain power and the phenomenon grows with a viral

behavior until the company suffers the worst, the end. 

This works against the freedom of information principle and employs "spin" to project the appearance of " politically correctness".



The spin culture uses media to distort messages, the truth and hide the information



Often governance issues generate an unhealthy culture – silos or the division between business and IT. It exists because there are two different organizations with different objectives, plans and roadmaps. So they do not concur to deliver together. They have different missions and products, it is that simple. The EA governance and organization have to be set up so that the concerned business and IT groups have same leadership and goals. 119 Enterprise Architecture roadblocks and how to overcome them

Flows

Function O

Lines/Products

Process Technology People

Layers Planes

Culture, EA and politics 

The culture can be a fertile ground for politics. Nothing is achieved without playing the game.



Rumors abound about IT fearing the business reaction to the EA/SOA program,

unfortunately, too often initiated without a business case. –

IT, avoiding confrontation is probably substituting the EA and SOA terms with a discourse on benefits. Politicians, as well, in avoiding sensitive topics, come back with convoluted answers to respond to simple, closed questions.

– Too many prophets have jumped in the EA/SOA bandwagon adding to the IT pressure on business. “Do EA/SOA or …!” – Over-hype has already placed EA and SOA at the top of the hype curve where the credibility is not sustained yet by realizations. The IT history lessons would not concur to support the EA far-reaching claims; the result is that the business doubts it!

Flows Layers

D S

120

Function O

Lines/Products

Process Technology People

Planes

Business, EA and politics 

Although business is reacting to the technology push, they do not contest the benefits but they are painfully aware of the potential cost of disruption, which might break rather than make the company.



Business requires solid justification and careful planning before moving from the “status quo” to such a revolutionary course, as SOA.



Without critical business input, the resulting IT only Enterprise Architecture would

mainly provide the Applications, Infrastructure and may be the Data architecture, which is frequently the case, but not sufficient for releasing the goods of the EA: process improvement, agility, strategic planning etc. 

The business people will have little reason to consult it, the word spreads, and, progressively, the EA loses its momentum.



The loop is closed now. The business was right to doubt it, after all.

Flows

Layers

D S

121

Function O

Lines/Products

Process Technology People

Planes

Business, EA and politics i 

Business, as well, got tired of the exotic IT acronyms like WS, SOAP, REST, UDDI, WSDL, mashups, AJAX, ESB, BPM, BPEL, XML, UML, TOGAF… some badged 2.0 now (and technology is changing at an exponential rate these days - Ray Kurzweil’s law-, i.e. the situation is getting worse).



IT is not talking about Value Chain, business models, process improvement, Six Sigma, regulation, customer satisfaction, Balanced Scorecard, SWOT, KPIs, NPV, payback, the terms the business can understand.



Is the business providing the Business Architecture (process architecture, business information and vocabulary) necessary for IT to comprehend and align the technology? No.

Flows Layers

D S

122

Function O

Lines/Products

Process Technology People

Planes

Politics result in 

The net result of all this is – the great Business and IT divide and – an increasingly highly charged atmosphere progressing towards a blame culture.



And the solution is the EA, which – ought to mend all the evils of the Enterprise, – to cure the silo culture and – patch the divide between Business and IT.



In a nutshell, EA becomes the ground of the already existing political battle but, at the same time, the tool to mediate the political divide.

Flows Layers

D S

123

Function O

Lines/Products

Process Technology People

Planes

Why politics and remedy 

While the EA encompasses alignment of business, strategy, technology and people, the IT takes the driving role without business and top management support. – How is this supposed to happen? After all, more than half of the EA is not IT, i.e. business processes (how), strategy (why), information (what), organization (who)… – without a strong business leadership and participation, EA would lack political support and fail to deliver on its promise since IT alone cannot specify SOA services, improve processes, determine usefulness of information.



In this phase, the best you can do is



be convincing i.e. gain support for the EA business case which you should express in financial terms.



Spend energy to rally critical stakeholders’ support in business and top management. Involve them by planning adequate EA artifacts, in response to specific requests, explaining what is in it for them.

Flows

Layers

D S

124

Function O

Lines/Products

Process Technology People

Planes

Why politics and remedy i 

Thinking in many Enterprises is tactical, at best. – Firefighting would better express the facts. – The EA is strategic and accepted because of its strategy promise but it may become a lip service only, with its execution ever postponed in order to cope with tactical crisis. In truth, – EA will compete for resources with many other activities which have not been included in the EA scope, in the first place.



Supposing the EA development moves slowly; – it will be generating lots of tactical-strategic conflicts: people need solutions yesterday, the market cannot wait and the EA will provide the feature who knows when! – Tactical projects are approved then and co-exist and compete for resources with the EA program. Flows Layers

D S

125

Function O

Lines/Products

Process Technology People

Planes

Politics remedies 

There is no easy solution to this except delivery on time and fit for purpose.



To reassure everybody have a clear, simple plan in place that you are confident you can deliver to. You probably have one single try.



Deliver often, iteratively, emphasize value returned.



Prioritize business needs, deal with the EA trigger causes first, and deliver what the stakeholders requested.



This is a program, so business process discovery projects will probably have to be executed in parallel to Applications, Infrastructure, Data architectures and other streams. Then add views as DW/BI, Content Management, procurement processes,

network architecture etc. 

With a delivery plan in front, people can wait, if they trust you. Otherwise, tactical Flows

projects win.

Layers

D S

126

Function O

Lines/Products

Process Technology People

Planes

Mistakes generating politics 

There are execution mistakes: – ignoring important stakeholders, – not communicating properly or enough, – not consulting relevant people, – not referencing and recognizing contributions, to name a few, provoking the syndrome of "not invented here” i.e. you have not consulted us, where did this come from"?



Enterprise knowledge is locked in people’s minds. To release this collective wisdom you need negotiation skills, “selling not telling”. Otherwise the information you may get for the EA may be of little value.



Define an EA vocabulary and Frequently Asked Questions (FAQ) to avoid confusion and display the progress dashboard on the Web for transparency. Flows Layers

D S

127

Function O

Lines/Products

Process Technology People

Planes

Mistakes generating politics and remedies 

From your side, lack of EA development experience and poor definition of scope, deliveries, not fit for purpose, i.e. (typically large documents with poor focus) can increasingly deteriorate credibility as the development process is stalled by unusable outputs and by disputes about how the artifacts are to be used.



Agile processes with frequent deliveries and wide consultations will help make the process transparent and accountable.



EA roles and responsibilities have to be well designed to avoid overlaps generating confusion and conflicts and, in the end, politics. Work as a team is crucial as the domain and span of activities is much too large.



Bottlenecks have to be quickly discovered and eliminated. Observe EA inhibitors since they could stop your EA development early, and find ways to conquer them from the beginning.

Flows Layers

D S

128

Function O

Lines/Products

Process Technology People

Planes

Mistakes generating politics and remedies 

Accountability and empowerment, recognition and award as company values will pave the way to progressive success in eliminating a culture of politics.



After the first few deliveries, it is important to – police all other development work, – install EA compliance controls (checkpoints) in all relevant business processes, – provide training and easy access.

Otherwise your EA may be ignored, forgotten.

Flows Layers

D S

129

Function O

Lines/Products

Process Technology People

Planes

EA risks management 

EA is perceived as a threat as, in reducing duplication in process, platforms and projects, it creates people redundancies, it brings change.



The EA team must have a vast knowledge spanning business, IT and people issues

and be socially and politically astute. Selection of the proper EA team constitutes the major risk in this development. This team will not only have to develop the EA properly, but will have to explain it in simple terms everybody can understand, and then gracefully deploy EA compliance controls in all major business processes defeating the inherent resistance. 

The Enterprise Architect has to be politically literate to justify EA/SOA, argue the business case, rally support from stakeholders, keep management informed and optimistic, do the work and survive the process! Flows Layers

D S

130

Function O

Lines/Products

Process Technology People

Planes

EA change management 

Change Management (CM) becomes essential in the Enterprise transformation execution process since people can and will resist, will do partisan fighting since, after all, their job is at stake for no grander purpose.



CM has to work along to provide a path forward for all affected by the migration process to expose the greater good, to motivate. Early preparation is essential to avoid problems.

Flows Layers

D S

131

Function O

Lines/Products

Process Technology People

Planes

Current and Future Outlook

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

132

Function O

Lines/Products

Process Technology People

Planes

EA, current outlook 

The EA "body of knowledge" does not support the EA effort, since it is scarce, fragmented and contributed by practitioners rather than academia because: – EA crosses the boundaries between the theory and practice of business (existing since the dawn of time) and IT (still young and playful, celebrating about half a century of existence), disciplines that until now have been treated in utter separation. The Business side concocts a system specification, the business analyst translates it and the IT implements it. – Business and IT have different vocabularies and set of skills, objectives, plans and line management.



In current practice, the most adopted approach for structuring an Enterprise Architecture is the four layer architecture: business, applications, information and infrastructure. This, more often than not, leaves out: Flows Layers

D S

133

Function O

Lines/Products

Process Technology People

Planes

Current EA leaves out 

the people, the processes they execute and the organization alignment



other stakeholders' interests (other than customer's) i.e. the owner/shareholders/ investors, employees, community and as such, ignores supporting business functions, processes and technology



all other internal views, except for the main product view, omitting for instance, the Support and Development functions



all other IT stakeholders' views such as helpdesk, email, printing etc.



all operating technologies other than IT (assembly line, cooking equipment, bottling bands etc); as a consequence, EA may not serve large segments of industry well



134

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Current EA is IT only 

The problem with Enterprise Architecture and existing frameworks is that they are IT oriented, designed by IT for IT, ignoring the business views



What applications do without a picture of what business does?



Without a business architecture, the EA, mean: loose diagrams of a patchy collection of systems without the unifying picture of the business structure and delivery flows.



The lack of a business architecture may be the grounds for failure of Enterprise Architecture developments and SOA to deliver the touted benefits, a motive for subsequent management scepticism.

Flows Layers

D S

135

Function O

Lines/Products

Process Technology People

Planes

Current EA suffers from lack of business architectures 



Business talks about Value and Supply Chains not architecture VRM (Value Reference Model),



SCOR (Supply Chain Organization Model).



NGOSS (eTOM) framework for telecommunications is an exception.



the Business frameworks are all slightly different, a situation not dissimilar to that of EA frameworks.

Flows Layers

D S

136

Function O

Lines/Products

Process Technology People

Planes

Current EA lacks key views 

The context diagram and stakeholders' Use Cases are omitted



The process design is delegated to business people with no further control



Data architecture consists solely of a To-Be Customer Data Integration (CDI)

exercise 

The As-Is data architecture is seldom discovered for other types of data except customer’s.



Content Management and Data Warehouse/Business Intelligence are usually the object of separate activities, not integrated to the EA.



There is frequently no security view



No navigation and often no EA tool and repository. Flows Layers

D S

137

Function O

Lines/Products

Process Technology People

Planes

SOA for WS and EA for key product only 

SOA is initiated for integration of a few isolated services, usually in the web arena, ignoring the big EA picture; as such it does not re-use or enable agility.



On the technology side, EA does alignment, standardization and integration.



EA usually represents the architecture i.e. the structure and operation blueprint of IT the applications and technology delivering the main product, in an attempt to simplify and standardize technology.

Flows Layers

D S

138

Function O

Lines/Products

Process Technology People

Planes

The EA reality: EA ends up anywhere 

End to end performance is not managed simply because the human contribution is not accounted for in the EA framework.



At best, EA can be called an Enterprise IT architecture and most probably, would raise little interest from potential stakeholders.



EA development can easily end up anywhere in the absence of an agreed definition or framework, since there is too much variability in terms of scope and deliveries.

Flows Layers

D S

139

Function O

Lines/Products

Process Technology People

Planes

The EA future outlook 

EA is a necessary "evil". Any system needs a blueprint enabling proper operation, maintenance, planning...



To fulfill the expectations, EA needs to satisfy its many stakeholders in top management, business, technology/IT and organization – EA will finally be recognized as a business discipline, having incorporated Value Chains, Business Models, Strategic Planning... – The EA evolves to increasingly cover business architecture rather than IT alone; the Enterprise Architecture will be the result of the fusion of IT, Business and Organization/People architectures; because, what is the value of an applications architecture, without the process it implements or the people operating it? – The governance for EA will be more & more business and top management heavy; this is because it would be used in mapping the strategy to components, to derive the enterprise transformation portfolio, make investments and take strategic and tactical decisions.

Flows Layers

140

Function O

Lines/Products

Process Technology People

Planes

The EA future outlook i – The EA development will be increasingly triggered by Mergers & Acquisitions and outsourcing activities; IT BPO, SaaS(ASP) riding a strong current right now. – The EAwould be more and more called in the business decision making process; because the EA architect deals with the business logic, technology operation and strategy, is able to understand both worlds and use both business and IT vocabularies. – A combined EA framework emerges to take advantage of the strengths of various frameworks, such as Zachman, TOGAF, FEA and others. – SOA is recognized as part of the EA program as the target EA style of architecture and technology, rather than executed in isolation as it often happens – EA would be increasingly required by shareholders/owners/investors to provide the blueprint of the business operation to describe assets, provide proof of regulatory compliance, map costs and profits on various operations and align strategy. The US government mandates EA to the public sector. EA would become a regulatory feature for public listed companies.

Flows Layers

D S

141

Function O

Lines/Products

Process Technology People

Planes

The Virtual Enterprise

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

142

Function O

Lines/Products

Process Technology People

Planes

Virtual Enterprise: Collaboration, Outsourcing, SOA & WS 

To succeed in Today’s business world, competition is not enough. Partnerships – part of the Value Chain -, strategic alliances and collaboration are required



Most non-core Functions of your organisation can be outsourced to partners



The difference in cost-efficiency, performance and agility of the Enterprise between an “on demand” or pay per usage outsourcing model and an onpremises and self manned function is determining the choice of outsourcing



Speculation arises about the virtual Enterprise, an Enterprise that is almost

entirely outsourced 

It can be successful assuming it employs best of breed outsourced services in a virtual Value Chain implementation, emphasising collaboration



SOA enables the definition of virtual Enterprise services and the WS technology enables the automation of workflow between partners over B2B interactions Flows Layers

D S

143

Function O

Lines/Products

Process Technology People

Planes

Value Chains and Networks 

Porter conceptualized, in the 80s, the Value Chain (VC) of an Enterprise. A VC categorizes the business functions of a company in primary (operations) and secondary (support) functions.



Porter also introduced Value Networks or Systems consisting of a string of Value Chains contributing to the delivery of the end product or value, where each VC is implemented by a separate Enterprise.



A business model specifies, amongst other, the specific way a firm approaches and segments the market, delivers value to its customers, manages relationships with customers and partners, and customizes its value chain and core capabilities to return revenue. Ultimately, the business model characterizes

"the architecture of the firm and its network of partners". Flows Layers

D S

144

Function O

Lines/Products

Process Technology People

Planes

Business Architecture based on VCs and Operating Models ď ą

A Business Architecture should be structured on the Value Chain, the Business and the Operating Models of the Enterprise, since this is how the business perceives architecture.

ď ą

The Operating Model is the necessary level of business process integration and standardization for delivering goods and services to customers as quoted earlier. Business units should be integrated and standardized to various degrees according to business needs, There is no point in standardizing the

implementation of a SOA or SaaS service since the implementation is hidden behind interfaces.

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

145

Function O

Lines/Products

Process Technology People

Planes

Virtualization and Outsourcing 

From a technology viewpoint, IT virtualization makes inroads in the Enterprise by decoupling the concerns between business and IT, and between applications and technology, while enabling outsourcing. Technology virtualization allows the creation of abstract services, hiding their physical implementation, and enables their exploitation over generic interfaces.



Many business functions of your organization (ultimately all) can be outsourced. What traditionally was considered to be core functions is no more a sacred

territory for outsourcing. The difference in cost and efficiency between an "on demand" or pay per usage outsourced service and an on-premises and self manned typical function could be significant and hard to ignore.

Flows Layers

D S

146

Function O

Lines/Products

Process Technology People

Planes

Virtualization and Outsourcing 

This raises speculation on an Enterprise that outsources most or all its business functions but retains governance for planning, coordinating operations, budgeting and making all key decisions. In a Wikipedia definition "a virtual organization is a firm that outsources the majority of its functions".



And another definition from Abbe Mowshowitz (1994): "the virtual organization is a temporary network of autonomous organizations that cooperate based on complementary competencies and connect their information systems to those of

their partners via networks aiming at developing, making, and distributing products in cooperation". See www.virtual-organization.net. 

The Virtual Enterprise (VE) can be successful, assuming it employs best of

breed outsourced services in a "virtual" Value Chain implementation consisting of company and partner links.

Flows

Layers

D S

147

Function O

Lines/Products

Process Technology People

Planes

The Virtual Enterprise 

The virtual SOA Enterprise is, debatably, the future of the entrepreneurial world specialising in management and decision making while outsourcing most of the Functions of the today Enterprise



The question is, what defines the virtual Enterprise then?



The Governance Function defines the virtual Enterprise by retaining decision making and business model specification and implementation through partnerships assembled in the virtual value chain – Its Operations, Enterprise Support and Development are outsourced to partners – becoming part of the Value Chain – Planning, budgeting, risk management, cost and performance monitoring, branding can bb out sourced as well



The business model, promoting collaboration, is illustrated by the architecture of the firm and its network of partners contributing to the Value Chain Flows Layers

D S

148

Function O

Lines/Products

Process Technology People

Planes

The Virtual Enterprise basic features 

A VE operates over a virtual Value Chain i.e. a chain whose links are owned by company and partners, blurring the borders between the Value Chain of the firm, and the Value Network it is part of.



The Governance is the business function that defines and identifies the Virtual Enterprise since most or all other functions of the Enterprise (primary and secondary in Porter's definition) could be outsourced.



The VE is defined by a new operating model promoting collaboration and B2B to take advantage of best of breed applications on the market. This VE business model is increasingly enabled by the adoption of business process outsourcing (BPO), application outsourcing - Software as a Service (SaaS) - and in general

by the fast adoption of infrastructure virtualization technologies, Web Services, SOA and collaborative technologies of the Web2.0.

Flows

Layers

D S

149

Function O

Lines/Products

Process Technology People

Planes

The Virtual SOA Enterprise design Virtual Enterprises

Company 5

Product Development

Company 6

Marketing Research Company 4

Company 1

Manufacturing

The Company Governance Company 2

Supply Chain

Company 3

Payroll

Other Companies Most Enterprise Functions outsourced outsourced Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

150

Function O

Lines/Products

Process Technology People

Planes

The Virtual SOA Business Model competitive advantage 

A business model – specifies how a firm delivers value to its customers – describes the choice of products per market segment, their costing and pricing and the customisation of the value chain by establishing core assets and noncore capabilities delivered in partnership



The virtual SOA Enterprise results from a new business model promoting collaboration to benefit from best of breed processes and applications



The competitive advantage of the virtual company is the result of an efficient

Business Model and best of breed Value Chain capabilities 

The Virtual Enterprise exists already e.g. – Virtual Operators or Service Providers which re-sell minutes and phones – Restaurant franchise chains

Flows Layers

D S

151

Function O

Lines/Products

Process Technology People

Planes

The Virtualization of Enterprise IT 

The interface between business and IT is quite convoluted and low level, leading to business having to understand and take decisions about IT and IT having to understand the business workings.



That's why, when simple business meetings to discuss IT capabilities become debates on the merits of WS SOAP relative to REST, the communication between business and IT breaks down.



Technology choice should be in the IT domain rather than on the business agenda and business should be able to change processes, rules and content directly without IT intervention.

Flows Layers

D S

152

Function O

Lines/Products

Process Technology People

Planes

The IT virtualization 

In this fast moving world, the business in an Enterprise, its logic, should not depend on IT technology, that is, its type or implementation.



Business activities would be performed careless to technology and fearless to tomorrow's new IT hype. Why bother with what type of infrastructure or platform - COBOL, JavaEE or .NET, Smalltalk, 4GL or AS400 RPG -! At the same cost/performance, this should be an IT choice which surely would change in the future.

Flows Layers

D S

153

Function O

Lines/Products

Process Technology People

Planes

The IT virtualization i 

Business should be willing to adopt technology virtualization to be able to interact with IT technology at a service level, where the negotiation between business and IT is performed in a contractual communication language, structured in terms of capabilities, relative feature merits and their cost. IT functional and non-functional capabilities will be delivered under SLAs at an agreed price.



IT virtualization is adding an welcome interface layer, hiding the IT

implementation complexity and technology. It represents a significant step forward in patching the divide between business and IT, often materialized in the blame culture we all know, since business people can then make abstraction of the IT infrastructure, issues, terminology... Flows Layers

D S

154

Function O

Lines/Products

Process Technology People

Planes

The IT virtualization ii 

No amount of good will solve this divide until a good insulation (interface) virtualization layer is inserted between the two. Business and IT will talk the language of business: services, QoS, SLAs, capacity, security, a vocabulary they all understand.



The business does not have to talk or understand IT any longer, and vice versa, and could for the first time, be in charge of business processes.



IT, in turn, becomes a true business service provider negotiating SLAs and licenses, very much like an ASP (Application Server Provider). An IT application suite would be offered as a set of business services now. In this respect, new types of outsourcing services such as, Software, Platform or Integration as a

Service have recently appeared. Flows Layers

D S

155

Function O

Lines/Products

Process Technology People

Planes

The EA layers virtualization 

Typical Enterprise Architecture (EA) layers: business, information, applications and infrastructure. One might add people/ organization and non-IT technology which are sometimes neglected.



Layers though, can be virtualized. This is the way it is done in the network OSI (Open Standard Interconnect) standard where each of the layers provides services over an interface to the layer above.



In the Enterprise space, the virtualization appears to seep upwards across EA layers, from infrastructure to applications and business processes.

Flows Layers

D S

156

Function O

Lines/Products

Process Technology People

Planes

The Virtualization of IT infrastructure 

A hot topic now in the Enterprise, is, quintessentially, about providing an abstraction to the IT technology: servers, storage and networks. It is about an interface layer hiding the infrastructure implementation and its platform types. The benefits appear to be compelling: server utilization grows inverse proportionally to the number of servers, the cost of the occupied real estate and cooling.



What does infrastructure virtualization promise? Independence from the HW

infrastructure. Multiple applications and OSs run on one or multiple physical servers. Virtualization is supported by blade systems as well, where processing power is modularly scaled.

Flows Layers

D S

157

Function O

Lines/Products

Process Technology People

Planes

The Virtualization of IT infrastructure i 

Processing power can be consumed "on demand" (IBM parlance); MIPS can be purchased in an "utility" like model (HP talk). Storage will be retailed as a commodity from a pool and I/O is ultimately virtualized.



An analogy can be made to the networks world where the leased physical lines evolved into virtual circuits, VPNs with QoS characterizing a virtual channel.



Virtualization evolves to “Real Time Infrastructure” that enables configuration, scaling of applications and dynamic allocation of computing resources as dictated by business calendar or load.



Virtualization provides light and less costly business continuity and easier management. Ultimately the infrastructure can be outsourced to a 3rd party and paid per usage. Flows Layers

D S

158

Function O

Lines/Products

Process Technology People

Planes

Applications layer virtualization 

At the EA application layer, virtualization is provided by SOA through standard interfaces and encapsulation, hiding the implementation technology. In addition, SOA provides the standard integration technology with communications implemented over standard protocols and interfaces



SOA provides an abstraction layer above applications hiding the communications and applications implementation technology. It should not matter any longer how the applications and network are realized or what the

platforms are. Applications are in effect virtualized and offered as services. 

Inside the application layer, Java and .NET have already introduced a virtual machine abstraction layer between the applications and OS, and Application

Servers are providing even more abstracted functionality by adding distributed transactions, persistence, security and other horizontal capabilities.

Flows

Layers

D S

159

Function O

Lines/Products

Process Technology People

Planes

Business layer virtualization 

Workflows would be implemented by process and rules engines as orchestration of SOA and Web Services listed and described in a catalogue (UDDI, WSDL).



This abstracts away the complexity of IT and its applications under a layer which business people can understand, and now, model business processes themselves. They would be able to design and change processes using BPEL (Business Process Execution Language), as a composition of SOA and SaaS business services, using graphical interfaces.

Flows Layers

D S

160

Function O

Lines/Products

Process Technology People

Planes

Information layer virtualization 

For the EA information layer, MDM (Master Data Management) adds a similar virtualization layer since most application will now utilize information provided by this layer/hub rather than supplied by all other applications. The MDM implementation may be integrated to SOA since the MDM hub could become a SOA service for information access.



This will constitute a data abstraction layer for services and people using the information.

Flows Layers

D S

161

Function O

Lines/Products

Process Technology People

Planes

User Interface virtualization 

From a User Interface point of view, the fine grained Web2.0 interactivity further abstracts IT technology from business logic by providing a universal, ubiquitous web client, independent of application and its implementation with the performance of client server applications.



An abstraction layer is introduced which consists of web servers understanding AJAX, Adobe Flash and MS Silverlight-like technologies.

Flows Layers

D S

162

Function O

Lines/Products

Process Technology People

Planes

IT virtualization summary 

IT virtualization appears at the interface between EA layers, at the same time. At the EA business layer, the business process orchestration and rules engines provide business people with the tool to rapidly change the Enterprise workflows and rules without support from IT.



At the EA application layer, virtualization is provided by SOA through standard interfaces and encapsulation of application, hiding the implementation technology. What is more, SOA provides the standard service integration

technology. 

At the EA information layer, MDM (Master Data Management) adds a similar virtualization interface since most application would utilize the information

provided by this layer rather than supplied by all other applications. Flows Layers

D S

163

Function O

Lines/Products

Process Technology People

Planes

IT virtualization summary i 

IT infrastructure virtualization adds an interface layer, hiding the technology implementation complexity and enabling efficient management of the processing capacity, storage and networks bandwidth. The IT infrastructure progressively more becomes a “real time”, on demand service.



Overall, the virtualization of IT provides technology services to business through defined interfaces which eliminate the nowadays tangled business-IT interaction, and provide abstraction interfaces between the EA layers of the

Enterprise. There are multiple vertical and horizontal dimensions to the Enterprise virtualization about to happen or already happening.

Flows Layers

D S

164

Function O

Lines/Products

Process Technology People

Planes

Virtualization guidelines Companies could deploy IT virtualization technologies in combination with outsourcing strategies as for instance (see picture): 1.

entirely outsourced business processes (including the people operating them) through Business Process Outsourcing

applications outsourced to Software as a Service, SaaS providers (or ASPs) with own people operating

application managed services where only the managing of your Applications and Infrastructure is outsourced

the whole IT infrastructure outsourced to dedicated data centers.

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

165

Function O

Lines/Products

Process Technology People

Planes

Virtualization forecasts 

The IT virtualization will be pursued at all layers (BP orchestration and rules, MDM information, SOA services and integration, IT infrastructure).



Soon, Enterprises will be consciously designed out of SOA and SaaS services.



The business would take charge of its business processes through direct orchestration of SOA and SaaS services and direct access to the business rules technology.



Liberated from supporting most Value Chain functions, a company may focus on its business planning, investing and creative management activities. The company will be lean, composed of a mix of best of breed outsourced services.



Other companies in the virtual Value Chain will similarly focus on fewer value chain links where they specifically have a competitive advantage like cheap or

Flows Layers

D S

qualified labor

166

Function O

Lines/Products

Process Technology People

Planes

Virtualization and Outsourcing 

The new Enterprise business model is based on collaboration, virtualization technologies and the outsourcing of links in the Value Chain.



Porter's Value System concept links the Value Chains of all firms participating in the product delivery process. Assuming, by extension, that each and every link of a Value System and Chain is represented by a different company, who manages the overall product delivery process, who plans and governs, which single entity represents the legal identity of the combined Enterprise?



Ultimately, the company consists of the Governance function which only orchestrates the whole process flowing through all companies in the Value System and assumes the legal identity of the Enterprise, for incorporation.

Flows Layers

D S

167

Function O

Lines/Products

Process Technology People

Planes

Virtualization and Outsourcing i 

This virtual SOA Enterprise results from a new business model promoting collaboration between outsourced best of breed processes and applications. It is proved by the increasing success of application (SaaS), data centre and business process outsourcing (BPO) and in general by the fast adoption of the collaborative tools of web technology and services.



This demands good relationships and a reliance on collaboration. The web services technology enables automated workflows over B2B interactions and

communications. SOA provides the structured architecture based on services enabling this distributed Enterprise. The www is then the ESB of your virtual SOA Enterprise.

Flows Layers



168

Function O

Lines/Products

Process Technology People

Planes

Enterprise virtualization and outsourcing

Customer GUI virtualisation

Technology

Outsourcing type People

Business Services orchestration Information virtualisation SOA Applications virtualization IT Infrastructure virtualization

Business Information BPO Applications Infrastructure

SaaS

Application outsourcing (SaaS/ASP) Virtual Enterprise, (BPO outsourcing) Managed Services

Data Centre outsourcing

Virtualisation, Outsourcing and the Enterprise Architecture layers

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

169

Function O

Lines/Products

Process Technology People

Planes

The Virtual Enterprise growth 

Its proved by the increasing success of application (SaaS), data centre and business process outsourcing (BPO) and in general by the fast adoption web hosted services



This EA Framework shows that if a Function of your Enterprise is outsourced, it becomes a GODS (Governance, Operations, Product Development and Enterprise Support) system, in fact a company to stand by itself.



In a Virtual Enterprise, all Functions are outsourced except Governance

Flows Layers

D S

170

Function O

Lines/Products

Process Technology People

Planes

EA Overview

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

171

Function O

Lines/Products

Process Technology People

Planes

The course content 

a model for building your Business Case for an Enterprise Architecture, the solution to the Enterprise problems, in terms senior management understands



an EA framework and metamodel



Enterprise patterns and Reference Maps – templates for building the architecture



an Enterprise strategy development flow and a number of best practices along the EA development process.



EA governance, program, site structure



EA politics, culture, the role of the Enterprise Architect, EA triggers, roadblocks, current and future outlook, the Virtual Enterprise Flows Layers

D S

172

Function O

Lines/Products

Process Technology People

Planes

EA (GODS BTP) FFLV Framework Overview i 

FFLV: Function - Flow - Layer - View – Three Layers: Business Processes, Technology and People

– Operations, Development and Support and Governance Functions (GODS) 

The Business Process layer – business information and strategy –

functional architecture as Flows over Functions from Value Chain



Technology layer, more than IT (non-IT)



People layer and their organization, culture, training…



Views, filters reflecting various stakeholders' concerns; a View is a filter showing only entities of concern. The totality of views in a layer: layer architecture



Interconnections as lines and products (outputs)

Flows Layers

D S

173

Function O

Lines/Products

Process Technology People

Planes

EA FFLV Framework Overview ii 

A navigation model easily implemented by a tool. – By clicking on elements of the cube such as Flows, Functions Layers, Views, Lines and Products various aspects can be displayed – By selecting a Line/Output, the connection details can be seen •



for instance an electronic transfer of an Order over an IP connection or a part moving over a production band

Based on a Model Driven Architecture (MDA) – Starting at the Value Chain Model – Down to business process and orchestration model (as SOA) – Mapped to applications and infrastructure with ERP modelling for re-using packaged applications



The FFLV is Open, views may be added as the EA development makes progress Flows Layers

D S

174

Function O

Lines/Products

Process Technology People

Planes

EA FFLV Framework Overview iii 

The framework unifies Business and Process (BPM) view with Technology and Organisation views



Links all architectural entities and artefacts in a navigable frame



Planning and roadmapping views through the When dimension



Aligns to Business Strategy with Why dimensions



A tool metamodel describes an EA object in a repository with attributes as Function/Flow/Layer/Views, Process/Technology/People and GODS Functions



performance attributes attached to Functions and Flows and to metamodel



It maps to other frameworks …

Flows Layers

D S

175

Function O

Lines/Products

Process Technology People

Planes

EA deliveries outline

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

176

Function O

Lines/Products

Process Technology People

Planes

Zachman on EA deliveries 

John Zachman suggested that EA artifacts be graphically presented: “I would further suggest that ultimately, the Enterprise will require that these artifacts must necessarily be graphically presented because at the point in time when you will need the artifacts, you won’t have the time to read through a thousand pages of text to attempt to discern their implications “



Wordy documents reduce drastically the audience!

Flows Layers

D S

177

Function O

Lines/Products

Process Technology People

Planes

EA Deliveries Outline i 1. Context diagrams with main stakeholders and their Use Cases 2. Present and future (with new functions) Functional architecture Views 3. Existing and target business processes Views for key functions and workflows

for products and important stakeholders 4. Existing and target application diagrams mapped against processes & functions 5. SOA services models 6. ERP application suites modelling outcomes 7. Existing and target technology (IT) Views

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

178

Function O

Lines/Products

Process Technology People

Planes

EA Deliveries Outline ii 8. Existing and target organization Views with units mapped against functions 9. Business Strategy mapping on the EA diagram 10. Technology roadmap, migration path and gap analysis

11. Transformation plan for first few iterations

ď ą

Each layer should be described by increasingly more Views as the EA work progresses through iterations. A View is a filter showing only entities of concern. The totality of views in a layer, if merged, will constitute the layer architecture.

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

179

Function O

Lines/Products

Process Technology People

Planes

EA Development process overview i 1. Form early EA design team 2. Assess EA business case (for each iteration) and get commitment. 3. Capture business information as Enterprise vision, mission, strategy, objectives, risks, planning and business model. 4. Design functional architecture starting from the Value Chain (GODS); a Function is a typical Enterprise activity. –

Illustrate Stakeholders' Use Cases as Flows (workflows to end activities performed by sequences of Functions) delivering documents and goods with SLAs.

5. Discover As-Is Enterprise Architecture. – Specify each Function in term of Process, Technology and/or People executing the Process; Technology consists of IT (Applications and Infrastructure) and non-IT technology . Flows Layers

D S

180

Function O

Lines/Products

Process Technology People

Planes

EA Development process overview ii – Do application suite (e.g. ERP) modelling that is the process of reverse engineering of the existent software packages. – Map stakeholders’ SLAs to performance KPIs associated to Flows and Functions. – Design selected Views (filters for various aspects of interest); include Security and Master Data views. – Describe current Enterprise organisation as departments made of Functions

6. Design transition steps and sketch To-Be Enterprise Architecture – Compile the applications and technology obsolesce roadmap – Specify Strategy and map it to Enterprise Functions and Flows to derive objectives and KPIs – Design target Functions, Flows, Products, SLAs, applications, infrastructure, views and organisation – Adopt SOA by specifying Functions as Services (which is quite an effort) and new organisation in terms of functions Flows Layers

D S

181

Function O

Lines/Products

Process Technology People

Planes

EA Development process overview iii 7. Assess the gaps between To-Be and As-Is 8. Plan Enterprise Transformation –

Establish EA governance and teams, create Transformation Project Portfolio, specify schedule, budget and project resources

– Define implementation strategies (Top-Down, Bottom-Up), deliveries and Critical Achievements – Assess changes and specify change management measures

9. Execute Enterprise Transformation Implementation iteration – Re-engineer existing processes and technology – Re-design and implement new organization (people) of the Enterprise – Document EA as you go using an EA tool

10. Re-iterate the process by adding new stakeholders and Flows, SLAs, levels of decomposition of Functions and Views Flows Layers

D S

182

Function O

Lines/Products

Process Technology People

Planes

Why use FFLV ď ą

The proposed FFLV model integrates most aspects covered by other frameworks. At its base, sits the four layer architecture model - business, information, applications and infrastructure - to which it adds:

the reference organization, business, applications and infrastructure architecture maps to help structure your firm architecture

the Single Page Architecture as a key artifact to establish a common vocabulary

and single view for all stakeholders 3.

the functional architecture, consisting of Flows over Functions describing the operation of the Enterprise

people and organization, to align business activities and technology to people roles and organizational departments Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

183

Function O

Lines/Products

Process Technology People

Planes

Why use FFLV i 5.

non-IT technology, in particular for including in scope many Enterprises using other technologies besides it

Views, to describe in a single diagram, solely the aspects of interest to a specific

stakeholder; they look like CT scan views of a body 7.

data, security, location, performance, financial and planning architecture views

widely accepted UML and MDA for IT modeling, beginning with the context

diagram and stakeholders' Use Cases 9.

Value Chains, Business and Operating Models, well known business concepts, harmonizing as such business theory and IT modeling

10.

SOA as the architecture and implementation style of target EA Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

184

Function O

Lines/Products

Process Technology People

Planes

Why use FFLV ii 11.

EA navigation, initiated from menus or, more conveniently, from the cube – vertically, up and down the function stack across layers and their views, at various degrees of detail of the Enterprise Tree – horizontally, from function to function along the products/lines

12.

an EA tool metamodel, by describing each EA entity in terms of the layers Views and Function attributes it is part of

13.

integrated view of Enterprise entities, rendering unnecessary mapping matrixes – structuring the Enterprise in a decomposition tree, browseable by business Function, Flow or Layer/View – naturally aligning strategy, processes, applications, information, infrastructure, people, and organizational units to business functions under the Value Chain

14.

Strategic planning, by cascading strategy objectives and execution projects to the EA tree Functions, Flows, Organization and Technology.

Flows

Layers

D S

185

Function O

Lines/Products

Process Technology People

Planes

EA benefits outline

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

186

Function O

Lines/Products

Process Technology People

Planes

EA benefits to the Main Stakeholders i 

To The Enterprise/The Company itself – initiate the development of EA to optimise the Enterprise armed with vision, a business case, best practices and a framework



CEOs – design governance (always forgotten) as a separate function and perform the decision making process



CTOs and Line-Of-Business executives – align technology investment to business objectives based on EA roadmaps and Programme Portfolio – measure performance with operational KPIs for each Function and Flow



CIO and Chief IT Architects – transform business strategy into Programme Portfolio consisting of IT programmes and technology roadmaps, Enterprise applications integration programmes, infrastructure simplification and optimisation Flows Layers

D S

187

Function O

Lines/Products

Process Technology People

Planes

EA benefits to the Main Stakeholders ii 

Business and Technology Strategists – EA framework tree supports mapping the strategy to each Function, process and job description – build a strategy according to given process put into action by and traceable to the Enterprise functions, processes and IT



Architects and Systems Quality Engineers – set IT architecture guidelines and technology standards in conformity and for the common Framework – approve common data vocabulary and methodology for the EA framework



Programme Managers – Enterprise Application/Programme Portfolio approach enabled by EA

Flows Layers

D S

188

Function O

Lines/Products

Process Technology People

Planes

EA benefits to the Main Stakeholders iii 

Owners, shareholders – understand how the Enterprise returns value to them by checking specific views ROI, ROA (Return on Assets)… ratios



Regulatory bodies – position compliance (SOX, Basel II, …) controls in EA process and IT applications Views such as financial

Flows Layers

D S

189

Function O

Lines/Products

Process Technology People

Planes

EA Benefits Summary 

Enterprise Architecture is the bridge between business and technology domains, a tool used by both sides to cooperate in achieving the Enterprise objectives: – The architecture serves as an Enterprise blueprint for design, modelling and enhancing comprehension of all stakeholders – EA enhances Business Communication, Quality Management and Evolution Roadmap

– Enterprise Architecture allows a company to treat all of its assets and projects as portfolios – An Enterprise Architecture enables deployment of quality standards as •

SEI’s CMM measures the maturity of an the Enterprise operation

•

Six Sigma is a business improvement tool useful for target EA

•

Compliance frameworks as SOX are based on Business Process controls, including Document Management and Finance/Accounting processes

Flows Layers

D S

190

Function O

Lines/Products

Process Technology People

Planes

The Benefits



EA is an essential Asset of your Enterprise



Enterprise Architecture allows long term investment planning



Ultimately EA is a Competitive Advantage by enabling faster product delivery at lower costs and agility to change

Flows Layers

D S

191

Function O

Lines/Products

Process Technology People

Planes

The Enterprise Transformation 

EA, like Strategy, is about long term thinking. It is the way an Enterprise can survive the furious rate of change and competition, the increasing acquisitions and outsourcing trends and the exponential increase in complexity and amount of information.



The Enterprise evolves from the current state and mission towards a vision with

stated goals and quantifiable objectives. 

The problem statement clarifies what the problems are and why are you doing it. The Strategic directions (strategies) determine the key programs of

transformation by stating in sufficiently general terms what needs to be done to achieve the goals, how the transformation takes place. By implementing the transformation program the Enterprise moves from one state to another towards the visionary state.

Flows Layers

D S

192

Function O

Lines/Products

Process Technology People

Planes

As is State A

The Enterprise Transformation process Iteration 1

Iteration 2

Iteration 3

Mission Statement

Enterprise Project Portfolio Management implementing EA roadmap to strategic goals

Problem Statement

Six Sigma projects Process Automation projects EA Development …

New Markets/Products Development projects

Business Technology People

…

Business Technology People

Current Enterprise

to Be State B

Vision Statement/ Goals & Targets Improve Product Quality Improve Process Efficiency Simplification Diversification

Business Technology People

Future Enterprise

Enterprise Transformation Process; executed as an Enterprise Portfolio affects Business Functions, Processes, Technology and Organization

Flows

193

Layers

D S

Function O

Lines/Products

Process Technology People

Planes

To Do or Not To Do Enterprise Architecture 

Imagine you chose Not to develop an Enterprise Architecture, while your Competitors do it. As our analysis shows, your products will reach the market later, will be less reliable and your investors will lack confidence because your Enterprise has no operating blueprint and the strategy is poorly executed since it is not mapped to technology. Where does this leave you?



Finally, the answer to the question

”To Be or Not To Be” Enterprise Architecture" is… “To Be”!

Flows Layers

D S

194

Function O

Lines/Products

Process Technology People

Planes

Good Reasons for To Do 

since the collective knowledge about the Enterprise, currently locked in many heads, will be at last released, documented and published;



the Enterprise will be blueprinted,



the projects executed as an Enterprise portfolio with a combined ROI manifold increased.



The divide between business and IT and the silo organization will be issues of the past.



Care should be taken though, as the costs of developing an Enterprise Architecture can render the Business Case negative as shown in our model. Focus, best people for the task, a proper EA framework, and tight control are essential. Flows Layers

D S

195

Function O

Lines/Products

Process Technology People

Planes

The Final Word Ultimately, EA is promising you a Competitive Advantage 

by streamlining your Enterprise,



enabling faster product delivery at lower costs,



handling the exploding amount of information and



providing greater Enterprise agility to cope with change. EA is an essential Asset, the knowledge DB of your Enterprise. The hypothesis and conclusion of this book is that the EA will offer the Enterprise the edge needed in the survival race.

Flows Layers

D S

196

Function O

Lines/Products

Process Technology People

Planes

Course Overview

Flows Layers

D S

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

197

Function O

Lines/Products

Process Technology People

Planes

Course Overview i 

Goal, Scope & Audience



The Enterprise Problem & the Solution – Enterprise improvement trends



About Enterprise Architecture



EA Drivers



EA Benefits



EA Business Case – Return On EA (RoEA), NPV

Flows Layers

D S

198

Function O

Lines/Products

Process Technology People

Planes

Course Overview ii 

EA Support Technologies – eXtended Markup Language – Enterprise Resource Planning – Enterprise Application Integration

– Web Services, WS

– SOAP XML, REST – Enterprise Service Bus, ESB – Universal Description, Discovery and Integration, UDDI

– Service Oriented Architecture

– 6 Sigma

– EA versus SOA and WS

– Capability Maturity Model, CMM

– SOA versus ERP, BPO, SaaS

– IT Information Library, ITIL

– Business Process Management

– COBIT

– B2B, EDI, ebXML – BPM, BPEL, B2B – Business Process Execution Language (BPEL) – BPEL, WSDL, UDDI, XML

– Val IT – Compliance

– Balanced Scorecard – Agile Processes, AP Flows Layers

D S

199

Function O

Lines/Products

Process Technology People

Planes

Course Overview iii 

EA History and Frameworks



EA Framework definition – EA frameworks types – The EA Framework scope – Description by analogy to a human body – EA Entities definitions

Flows Layers

D S

200

Function O

Lines/Products

Process Technology People

Planes

Course Overview iv 

The FFLV Framework Specification – Enterprise context, Stakeholders and Use Cases – Enterprise Functions, Value Chain and Business Model – GODS Enterprise • Enterprise Governance • Enterprise Operations • Enterprise Development • Enterprise Support

• Enterprise Functions in GODS structure

– Functions and Flows Logical Architecture • Product delivery Flow, Customer’s view • Combined stakeholders’ Flows

Flows Layers

D S

201

Function O

Lines/Products

Process Technology People

Planes

Course Overview v – Enterprise Layers: Business Processes, Technology, People • An Enterprise Flow: a sequence of Function stacks

– The Enterprise Cube dimensions: Functions, Flows, Layers/Views – Architecture Principles

– Technology Transformation Guidelines – EA Framework Metamodel – EA FFLV Views Specification • Layer specific and Enterprise Views

• Business and Process Layer Views • Technology Applications Layer Views • Technology Infrastructure Layer Views • People Layer Views

Flows Layers

D S

202

Function O

Lines/Products

Process Technology People

Planes

Course Overview vi – EA FFLV Views Specification • Enterprise Views: Security • Enterprise Views: Location, Business Continuity (BC) • Enterprise Views: Planning and Evolution 

Enterprise Data Architecture and Design Process



The FFLV Framework Navigation – The EA Framework Navigation Cube – The EA Framework Decomposition Tree – The FFLV Products/Lines – The FFLV Navigation Screen – The FFLV Navigation Menus

Flows Layers

D S

203

Function O

Lines/Products

Process Technology People

Planes

Course Overview vii 

FFLV Mapping to EA Frameworks – Zachman Mapping



EA modeling – Business Process vocabulary – Business Process swimlane diagram – A Use Case concept

Flows Layers

D S

204

Function O

Lines/Products

Process Technology People

Planes

Course Overview viii 

As-Is EA development exercise, facilitated practical session – Capture Stakeholders’ Requirements as Use Cases – Specify Enterprise Functions – Specify Enterprise product Delivery Flow – Specify processes in Functions – Specify IT Applications for each Function

– Insert Technology Infrastructure in Functions – Add people resources required in each Function – Map Organization design on Functions – Add Information View – Merge Views

Flows Layers

D S

205

Function O

Lines/Products

Process Technology People

Planes

Course Overview ix 

As-Is EA development exercise, facilitated practical session – Cascade Business Objectives – Place Security Control in the Enterprise tree – Add Information View – Merge Views – Cascade Business Objectives – Place Security Control in the Enterprise tree



How to Use the EA Framework – EA framework for Mergers & Acquisitions – EA framework for outsourcing – EA framework for a Small to Medium Business (SMB) Flows Layers

D S

206

Function O

Lines/Products

Process Technology People

Planes

Course Overview x 

Strategic Planning EA alignment to Business Strategy – Business Strategy for Stakeholders – PESTEL Analysis for Macro-Environment – Sample Strategies for Stakeholders – Strategy balance for Stakeholders – Strategy cascaded to the Enterprise

Flows Layers

D S

207

Function O

Lines/Products

Process Technology People

Planes

Course Overview xi 

Enterprise Architect’s Best Practices – Value of Best Practices – Establish EA Scope, Mission, Deliveries & Business Case – Determine EA Team and Governance – Specify EA Framework, EA tool and Design Strategy – Specify an Implementation Strategy – Plan Early Organization Change

– Discover As-Is, Design To-Be – Assess Gap between As-Is and To-Be – Plan and Execute Business Transformation

Flows Layers

D S

208

Function O

Lines/Products

Process Technology People

Planes

Course Overview xii 

Enterprise Architecture Tools



EA Triggers and Inhibitors



EA maturity



EA Overview – EA FFLV Framework Overview – EA deliveries outline

– EA Development Process Overview – EA benefits outline 

What EA will change



Virtual SOA Enterprise Flows Layers

D S

209

Function O

Lines/Products

Process Technology People

Planes

Course Overview xiii 

Annex – EA Governance, example – A Stakeholder’s Flow – How to use the EA framework

Flows Layers

D S

210

Function O

Lines/Products

Process Technology People

Planes

EA Governance, example

http://e-cio.org/lea_lab.htm#The%20Online%20Technical%20Reference%20Manual%20%20Prototype

Flows

Enterprise Architecture Development & Strategic Planning Training Course Copyright Adrian Grigoriu ÂŠ 2007-9

Layers

D S

211

Function O

Lines/Products

Process Technology People

Planes

Enterprise Architecture Experience 

EA framework for Qantas Broup



Solution Architecture integration to EA at Qantas



EA program design at Qantas



Energy and Content Management architecture at LogicaCMG



SDP functional Architecture Accenture/Telstra



MBF Enterprise Architecture 1st iteration



ASIC IT and EA maturity



3G Architecture and E2E Integration



Enterprise Architecture Framework



Service Delivery Platform Architecture



Integrated Network Architecture for the Global Target Architecture Framework Flows Layers

D S

212

Function O

Lines/Products

Process Technology People

Planes