EA & SOA AFCEA -Infotech2007

Copyright 2007, Semantech Inc. – All Rights Reserved http://www.semantech-inc.com

InfoTech 2007Semantech Lecture Series - 2007

Actionable EA & SOA Transformation – Putting the

Pieces Together

Presented byStephen Lahanas

AFCEA Infotech: October 23rd, 2007


InfoTech 2007

Introduction The Central PremiseUSAF IT AEA & Transformation SOI & Integration Patterns

Objectives for Today’s Presentation:

1. To present a more holistic view of Enterprise Integration from a philosophical context.

2. To review the current challenges facing the USAF IT community.

3. To present new perspectives regarding both Enterprise Architecture (EA) & Services Oriented Architecture (SOA).

4. To introduce novel approaches – and describe what constitutes Actionable EA…

I Actionable EA & SOA Transformation: Putting the Pieces Together


InfoTech 2007

Who am I? Architect, Engineer, Developer…

• Former Chief Engineer, WSMIS, USAF Decision Support PMO for Logistics• Former Lead Engineer, FEDM, USAF Data Warehouse Project (my connection to the case study)• Lead Enterprise Architect, DHS / USCG C2 Convergence Initiative• Lead Enterprise Architect, US Army AENIA NETOPS & APC Projects• Enterprise Architect on the FAA AIM Initiative• Lead Architect, Cisco System’s E-learning Architecture Team




InfoTech 2007

What is Enterprise Architecture ???


InfoTech 2007

What EA is, and why it is important…

1. Enterprise Architecture is a mechanism used to capture the nature & complexity of an (enterprise) entity or entities.

2. Architects utilize EA frameworks or metamodels which employ standardized notation paradigms.

3. Frameworks include: DoDAF, FEAF, ToGAF, Zachman, MODAF and some might include UML here as well.

4. EA’s are capable of expressing / characterizing massive amounts of information through visualization.

5. EA’s are also data driven and can link development, management, performance and other related methodologies.




InfoTech 2007


InfoTech 2007

Architecture is also all about process…

1. A typical Enterprise utilizes hundreds of processes or procedures, some of them are documented, repeatable and predictable - some are “dynamic.”

2. Process maturity is an exercise in control – however some types of process don’t respond well to control. In other words, they are not reducible – the variation is necessarily broad – thus the activity remains “intensive” in nature.

3. Enterprise architecture is process agnostic – it can illustrate how all processes interact within one another. This is critically important towards understanding how an enterprise truly functions.




InfoTech 2007

What SOA is, and why it is important…

SOA is the culmination of 15 years of IT best practices.

SOA begins to recognize the true importance of data inIntegration.

SOA begins to address the enterprise as a holistic entity…




InfoTech 2007




InfoTech 2007

What is ‘Actionable Enterprise Architecture’

1. After 10 years of practicing EA, we’ve begun to realize what the true value of the activity is.

2. Actionable Enterprise Architecture (AEA) is Agile, relevant and focused on problem-solving rather than compliance.

3. AEA provides mechanisms to combat or at least co-exist with complexity.

4. AEA is predicated upon the idea that architecture is only relevant IF it is traceable across an entire enterprise or program lifecycle. (and from top to bottom)

5. AEA recognizes that architecture and program methodology are symbiotic – the sum is greater than the parts.




InfoTech 2007


InfoTech 2007

AEA – Response to Lessons Learned

1. Architecture is synonymous with integration, not exclusive from it – when it becomes disconnected from engineering and integration it loses relevance.

2. Less is more – We have too many frameworks and they only get more detailed as time passes, this leads to inflexibility and meta-integration nightmares.

3. The processes supported by an EA must be accommodated in the EA. (if an EA is meant to support acquisition and engineering it must support representations of it & data capture that are relevant to those processes).




InfoTech 2007


InfoTech 2007

AEA – Response to Complexity Management

1. If an architecture activity adds to the complexity of an environment, it’s value proposition is negated.

2. EA or AEA is only valuable if it either helps to reduce complexity or manage it.

3. AEA links organizational levels, provides a common communication channel and represents the living history of the enterprise from a holistic perspective with the ability to drill down anywhere.

4. Managing complexity involves the ability to discern patterns and understand relationships across 1000’s of variables.




InfoTech 2007

The USAF Enterprise IT Environment

1. An excellent case study for complexity management.2. 1,000’s of systems x 100 (perhaps) of data interfaces, dozens

of organizational and functional domains, complex missions.3. High expectations for integration & cross domain

interoperability, thusfar not fully satisfied.4. Massive programs dedicated to managing the IT portfolio –

traditionally hampered by stove-piped processes and cultures.5. Still very difficult for leadership to gain a holistic view of

programs & portfolios or drill down for details. 6. Still perhaps over-dependent on expert ‘intuition’ to manage

many problem-solving scenarios.




InfoTech 2007


InfoTech 2007

Current USAF Enterprise IT Challenges

1. Data Transparency• The ability to exchange data across domains as needed• The ability to deconflict data

2. ERP Initiatives• Pent up demand for Logistics & Finance requirements

(nearly 4 years now)• Data layer & process reconciliation not mature

3. Cross Domain Interoperability• Most progress has been at infrastructure level• AF expectations for more sophisticated interoperability

also dependent on AF internal progress…




InfoTech 2007

How do we apply AEA to IT Transformation?

1. Begin with Semantics2. Use the Enterprise Architecture to define performance, quality

& capability expectations. Once defined in the architecture it can applied to all other program activities.

3. Capture process change, reengineering or reconciliation in the architecture – derive all process logic (BPEL etc.) from core process artifacts. It is must all be traceable, traversable.

4. Use the AEA to do your program level what if analysis / assessments. Model you future before you commit to it.

5. Integrate EA into your culture, it is the manifestation or living proof of continuous improvement.




InfoTech 2007

Step 1:


InfoTech 2007

Step 2:


InfoTech 2007

Step 3:


InfoTech 2007

Step 4:


InfoTech 2007

Step 5:


InfoTech 2007

What about AEA & ERP?

Some Radical Assertions (?):1. ERP as we know it will have already changed by the time the

USAF ERP initiatives are completed (FOC). 2. The pace of transformation is lagging behind industry.3. This has begun to affect and / or limit overall USAF capability.

Architecture serves as both the enterprise vision & the honest broker:1. It shows the history, there’s no hiding from it.2. It allows for visualization of multiple potential paths.3. It allows leadership the ability to see issues in context and

pinpoint trouble-spots before they become unmanageable.




InfoTech 2007

The number 1 risk to AF ERP right now is legacy transition and co-existence.

Managing ERP within a systems of systems (SoS) environment is something AEA can solve.


InfoTech 2007

Transformation is…

1. There at least three types of transformation:• Reactionary – not clearly motivated or directed.• Controlled – very heavily controlled, motivations are well-

understood.• Dynamic – exploratory, motivations aren’t fully defined.

2. An opportunity to redefine, reinvent or otherwise evolve into some more than existed before.

3. Increasingly unable to keep pace with the velocity of change within the IT industry.

Transformation is becoming more synonymous with Innovation…




InfoTech 2007

Innovation is dynamic and difficult to predict, however it is often times more successful at achieving transformation than controlled endeavors. AEA can support both approaches and in fact can contrast the relative benefits of either in any given situation.


InfoTech 2007

A New Idea ? Services Oriented Integration (SOI)

• SOA is the culmination of 15 years of industry efforts to remove interoperability barriers. Objects, patterns, services, exchange mechanisms are all designed to ‘normalize’ IT creativity.

• SOI recognizes the full potential implied by SOA (that potential is considered too expansive by many leaders in the SOA industry).

• SOI is the idea that SOA itself as a design methodology, set of best practices and best of breed tools lacks a central unifying principle.

• The principle is this: enterprise integration requires a ubiquitous integration fabric, based upon a simplified set of standards and rich user-driven semantics.




InfoTech 2007


InfoTech 2007


InfoTech 2007


InfoTech 2007


InfoTech 2007

SOI, Integration Patterns & AEA

• SOI is built on integration patterns just as OOD & SOA design build upon established patterns.

• Integration patterns are predicated on the recognition that as much as 75% of the integration scenarios & issues faced in an typical enterprise are commonplace (across any number of enterprises).

• They are also based on the notion that the enterprise local scope will produce its own patterns / common scenarios.

• This does not and will never capture / cover all issues but begins to reduce the need for multiple simultaneous invention in IT.

• Those patterns are captured by AEA…





Thank You for Attending…

For more information, contact:

Stephen Lahanas:[email protected]



Back-up Slides


InfoTech 2007


InfoTech 2007


InfoTech 2007

TV-1 Taxonomy

Example of Framework Mapping


InfoTech 2007

Technology

EA & SOA AFCEA -Infotech2007