The Role of Service Oriented Architecture within an Enterprise Architecture

This is the talk I prepared for The Enterprise Architecture Conference 2005, held in Sydney over the 8th to the 10th of August 2005. I was Head of Architecture, Distribution at NAB, and the deck introduces me that way. The deck is the only record I still hold of the event — nothing in the file says which of the three days my session fell on. It is the descendant of the SOA talk I gave at Ark Group’s conference that March, grown from ten slides of argument into twenty-three slides of case study: what it actually took at MLC to sell services orientation to management, govern it, and prove it in a proof of concept.

The file began life as a copy of the March deck — its internal Title property still names the March conference — and was created on the 9th of March 2005, revised thirty-nine times, and last saved on the 10th of July 2005, a month before the conference. Its “last printed” stamp of January 2001 belongs to the NAG corporate template it was built from, as with the BTELL deck of 2003, and PowerPoint carried it forward. As with the other decks reproduced on this site, what follows is necessarily brief — a deck is scaffolding for a person standing in front of it, the argument lived in what was said between the slides, and there are no speaker notes in the file.

All twenty-three slides are reproduced, one to a section, at the deck’s own numbering. Four carry drawings, converted to vector figures from the deck itself: slides 9, 10, 15 and 18. Where prose sits inside a drawing — the panel bullets on slide 9, the three panel texts on slide 10 — it is set out again as text after the figure, to be readable as text; slide 15’s two lead bullets sit outside its drawing and are set as text only. The slide titles are the section headings rather than repeating in the figures, the Wingdings bullets throughout are ordinary list bullets here, and the slide page numbers are not carried.

Two slides draw scoring tables whose cells are quarter-filled “Harvey ball” glyphs, and both are re-set as tables with the glyphs transliterated: slide 13 to the words its own legend supplies, slide 14 to the 0–4 scale its “Best 4, Worst 0” legend defines. The ball values were measured from the file’s drawing geometry rather than read by eye, the method was checked against both slides’ legends, and the four column totals it yields for slide 14 — 32, 28, 37 and 47 — agree exactly with the totals the slide itself prints. Slide 12’s two panels are numbered lists whose pairing of number to item is rebuilt from the shapes’ coordinates rather than the file’s drawing order; slide 13’s left column, where a project name spans several rows of hypotheses, is flattened so each row names its project and sub-project in full; and slides 16, 17 and 21 re-set their panel layouts as headed lists and tables.

Three repairs to conversion faults are worth naming. The converter prints the second line of a rotated two-line label on top of its first, which overprinted the twelve vertical band labels on slide 10’s figure; each second line is put back using the file’s own geometry, with LibreOffice’s PDF rendering of the same slide as the reference. The converter also re-wraps text to its own metrics, sometimes breaking a word mid-way: “Preferred Position” on slide 15 arrived as four fragments, and slide 18’s “Effective deployment of MQ” broke inside “deployment” while its “Reuse CRMS (back-end)?” callout gained a line and overflowed its box; each is re-set on clean lines within its own box, from the file’s text. Left as they stand: the tiny login-dialog mocks on slide 10 still break “Password” mid-word in conversion, at a size where it cannot be seen; and slide 10’s integration-band labels genuinely poke past their thin grey bars on the slide itself — the author drew those text boxes two lines tall — so they are left exactly as drawn.

The file also holds more than it shows, and none of it is repaired away. Slide 16 exists twice over — once as live text and once as a pasted metafile picture of the same table, stacked — and is reproduced once. Slide 18 carries two copies of one question callout a third of a millimetre apart: the buried copy reads “to eb used”, the visible copy corrects it to “to be used”, and the figure keeps both as drawn, corrected copy on top. Slide 5’s four quotation cards overlap on the slide, concealing runs of two of the quotes; the full texts are all in the file and are restored here. The exhibits pasted in from internal MLC decks keep their source decks’ own footers — the “Slide 2” caption inside slide 15’s figure stays, and slide 14’s “Slide 14” caption is not carried. Slide 14’s options 3 and 4 sit inside red-rimmed ellipses on the slide, 3 shaded grey and 4 light blue, with the slide’s two callouts set here as text beneath the table. Slide 17 anonymises its project leads and cost to “XXX”, “YYY” and “$ZZZ” — the deck’s own doing, for an external audience. And slide 22’s puzzle-piece SHAPE logo, glossing that name as “Strategic Holistic Advice Proposition Enabler”, is a small raster picture and is not carried.

The words are the deck’s own throughout, slips included: “Sydney,Australia” on the title slide, “the initiation the Amazon program” on slide 8, “Use Interface” on slide 10, “MQ Serries” on slide 17, “the degree of of complexity” on slide 19, “Optionsand”, “understodd” and “chuncks” on slide 21, and slide 7’s first bullet trailing off at “roles and responsibilities aligned to”. Nobody proofreads a deck, and these are what the room saw.

Two slides come almost straight from the March talk — the “Just what is SOA anyway?” quiz, and the working definition folded into slide 4 — and slide 5’s four industry definitions went on to be quoted again in the BankTech.06 talk of July 2006. The case study itself is the same programme whose architecture team story I had told at BTELL’s Enterprise Architecture Conference in 2003.

The reproduction was verified against the file paragraph by paragraph: of the 481 source paragraphs long enough to check mechanically, 480 appear verbatim here or in the figures’ own text, the sole exception being the “Slide 14” caption already noted. The short fragments — “i2M”, “MQ”, “$ZZZ” and their kin — were checked separately within their own sections, and the check itself was proved able to fail by seeding five deliberate faults into a copy, all five of which it caught.

Download the presentation (PPT, 391 KB)

1 Title

The Role of Service Oriented Architecture within an Enterprise Architecture

Presentation to The Enterprise Architecture Conference 2005
8-10 August 2005
Sydney,Australia

Chris Tham
Head of Architecture, Distribution
National Australia Bank

2 Agenda

• What is a Service Oriented Architecture (SOA) and how does it relate to an overall Enterprise Architecture (EA)?
• Is SOA one of many “patterns” for EA or is it the underpinning foundation for implementing an EA?
• How would an organisation go about delivering an SOA as part of an EA?
• This case study talks about the National’s experience with EA and SOA and covers topics such as:
  • Selling SOA to management
  • Embedding SOA into the EA - challenges and opportunities
  • Aligning SOA to business strategy and process re-engineering
  • The role of BPM, EAI and Information Management technologies in supporting an SOA
  • How pervasive does an SOA need to be before it becomes enterprise-wide?

3 Just what is “SOA” anyway?

a) “The best thing since sliced bread” – guaranteed to cure cancer, solve world hunger, and retire Third World debt

b) Something to do with SOAP and Web Services

c) What my vendor says will be supported in their “Next Generation” product

d) Yet another meaningless Three Letter Acronym, to be replaced by another fad in 3 years

e) It’s the same thing as (OOP, RPC, CORBA, CICS, …)

f) All of the above?

4 What is a “Service-Oriented Architecture”

• According to Gartner, the term “service oriented architecture” was first coined in 1994 by Alexander Pasik (a Gartner analyst) as a synonym for “client/server architecture” (request-response model for interprocess communication)
• The current usage of the term has been expanded to incorporate IT concepts such as:
  • Distributed computing
  • Web services
  • Functional modularisation across applications
  • Object orientation
• Related terms include:
  • Business process modelling and orchestration
  • Composite applications
  • Reusability
  • Component Architecture
  • Enterprise Service Bus
  • Workflow
  • Virtualisation
• One working definition:
  • A Service Oriented Architecture is an application architecture within which key business functions are implemented as re-useable services with well-defined, invocable, interfaces, which can be called in a defined sequence to form business processes.

5 SOA – industry definitions

Service-Oriented Architecture (SOA) and Web Services: The Road to Enterprise Application Integration (EAI), Sun Developer Network (http://java.sun.com/developer/technicalArticles/WebServices/soa/)

SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A service is an implementation of a well-defined business functionality, and such services can then be consumed by clients in different applications or business processes.

SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn’t possible before in the sense that:

Services are software components with well-defined interfaces that are implementation- independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.

• Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
• Services can be dynamically discovered
• Composite services can be built from aggregates of other services

Develop a migration strategy from a legacy enterprise IT infrastructure to an SOA-based enterprise architecture, Artem Papkov (artem@us.ibm.com) (http://www-128.ibm.com/developerworks/webservices/library/ws-migrate2soa/)

“SOA is a component model that inter-relates the different functional units of an application, called services, through well-defined interfaces and contracts between these services”. Defined as such, SOA is a collection of patterns for building an enterprise-level integration layer between applications while abstracting those applications as services. SOA approach advocates the use of open standards, while not ruling out proprietary technologies where they are appropriate, when integrating applications.

SOA relies on exposing application functions as services that can be invoked by external parties. The commonly agreed aspects of the definition of a service in SOA are:

• Services are defined by explicit, implementation-independent interfaces.
• Services are loosely bound and invoked through communication protocols that stress location transparency and interoperability.
• Services encapsulate reusable business function.

Your Strategic SOA Platform Vision, Randy Heffner, Forrester

A style of design, deployment, and management of both applications and software infrastructure in which:

• Applications are organized into business units of work (business services) that are (typically) network accessible.
• Service interface definitions are first-class development artifacts, receiving the same degree of design attention (and more) as databases and applications.2
• Quality of service (QoS) characteristics (security, transactions, performance, style of service interaction, etc.) are explicitly identified and specified for each service.
• Software infrastructure takes active responsibility for managing service access, execution, and QoS.
• Services and their metadata are cataloged in a repository and discoverable by development tools and management tools.
• Protocols and structures within the architecture are predominantly, but not exclusively, based on industry standards (such as the emerging stack of standards around SOAP).

Service-Oriented Architecture: Theory and Practice, CORPORATE EXECUTIVE BOARD

Service-oriented architecture represents a framework facilitating integration and interoperability of disparate systems. A service-oriented architecture consists of three key elements: a collection of services, a connection protocol by which these services can be accessed and can access each other, and a repository containing a catalog of available services. The governing principle of service-oriented architecture states that applications implement a collection of business capabilities and each of these capabilities can in turn be implemented by services, specialized pieces of software that implement a single business capability. Standardization acts as the key to a successful service-oriented architecture; not only must all services have the same structure in terms of the interface they present to the outside world, they must follow a standard protocol for advertising what they do and how they can be accessed and used.

6 What is SOA in relation to an overall Enterprise Architecture?

Enterprise Architecture Definitions

• ANSI/IEEE Std 1471-2000 definition of architecture:
  • “the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”.
• Architecture description:
  • a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business.
• Architecture framework:
  • a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.
• Business (or business process) architecture
  • this defines the business strategy, governance, organisation, and key business processes.
• Application architecture
  • this kind of architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
• Information/data architecture
  • this describes the structure of an organization’s logical and physical data assets and data management resources.
• Technology/Infrastructure architecture
  • this describes the software infrastructure intended to support the deployment of core, mission-critical applications. This type of software is sometimes referred to as “middleware”.

[!NOTE] Service Oriented Architecture?

Definitions taken from TOGAF Version 8

7 Degrees of Service Orientation

• Services Oriented Organisation
  • Entire organisation modelled as a set of services, and roles and responsibilities aligned to
• Services Oriented Business Unit/Process
• Services Oriented IT
  • Every IT function defined as a service
• Services Oriented Architecture
• Services Oriented Project
• Services Oriented Application
• Services Oriented Infrastructure

8 Case Study of adoption of SOA within MLC

• 2002 IT Strategy and Enterprise Medium Term Vision led to the initiation the Amazon program.
  • Established a Strategic Architecture Forum to review and approve major architecture decisions
• Made a number of significant architecture investments that were fortuitously aligned to SOA
  • Enterprise Business Functions
  • J2EE Application Development Framework
  • Secure Application Development Guidelines
  • Logical Data Model
  • Enterprise Security Framework
• A set of “happy accidents” took us on the road to SOA:
  • The need for J2EE/.NET interoperability led us to consider the use of Web Services (in particular SOAP and WSDL)
  • The need to expose legacy functionality to front end applications led us to consider integration tools that are based on Web Services
  • The need to create a unified servicing desktop led us to consider the use of portal frameworks and composite applications
  • The need to create a single view of customer and aggregate data across multiple back-end systems led us to consider XML, business process management/orchestration and an enterprise service bus.
  • The adoption of SOA became more relevant when we realised our key vendors (IBM, Microsoft, Siebel, Oracle, SAP) were also on the journey of rearchitecting their products.

9 Example: Enterprise Business Function justification

Typical Scenario without EBF’s

• Higher cost associated with maintaining distributed access to EBF’s
• Minimal reusability across back-end systems
• Multiple EBF’s accessing the same back-end systems - duplication of functionality (and associated effort/costs to develop)

Typical Scenario With EBF’s

• Supports the delivery of reusable aggregated services to multiple channels
• EBF’s can access a business rules engine to minimise development effort when business rules change
• No need to maintain distributed EBF’s, e.g. located on Advisers PC.
• Integrates with the EAI services

10 Example: Evolution of EBF one year later …

Current Scenario

• EBFs have been defined as the mechanism for implementing business services (as per WM architecture)
• EBFs must rely on a number of common services to perform its functions. These include Use Interface, Integration, Security, Diagnostic services.

Problem Description

• The Integration & Rule Services, User Interface and Security services are being defined as part of the Wave 2 architecture initiatives.
• The EACV architecture approach is being finalized.
• The current EBF Framework does not define implementation level details for integrating EBFs with these common services.
• The architecture for interfacing Product EBFs and Customer / Adviser EBFs (EACV) must be defined.
• The architecture for integrating EBFs with security services must be defined.

Solution Approach

• Enhance the EBF framework with re-useable design patterns that define the architectural approach for addressing common design / implementation scenarios.
• Define the design patterns for integrating EBFs with each other, integration services, security services and monitoring services.
• Define the common re-useable services to be implemented within the J2EE Application Development Framework (ADF) to support EBF implementation.

11 Lessons Learnt

• Don’t start by describing the solution, start by articulating the problem
  • Initially, we told the SAF we wanted to implement a “batch hub for EAI” – this was ultimately rejected as the business benefits were marginal
  • In hindsight, if we had started by saying we had a “grand vision” and wanted to use Web Services, SAF would probably not have agreed either and raised concerns about the maturity of the concept
  • We then adopted the approach of articulating what problem we were trying to solve (ie., “J2EE/.NET interoperability”, or “the best way to expose legacy functionality”)
• Take management (ie. SAF) along on the journey
  • We presented the SAF with various options for solving the above problems
  • Regularly educate the SAF on key architecture concepts and industry trends
  • We updated the SAF regularly with our progress, and the strength of our hypotheses
  • We initiated Proof of Concepts to “road test” any new technologies
  • By the time we presented our final recommendations, the SAF was comfortable on the feasibility of the solutions, and that risks have been appropriately mitigated
• Take the broader organisation along on the journey
  • Roadshows to IT staff
  • Evangelisation to the business

12 Example: Articulating Architecture Issues that need resolving …

Current Architecture Issues Being Resolved…..

1. Review and recut the Infrastructure Design for Amazon given the changes in the Masterplan
2. Close out the Solution for foundation (i.e. Strategic ECV & EAV vs Tactical ECV & EAV)
3. Given the new technologies and frameworks involved determine how to progress an end-to-end proof of concept.
4. Finalise the LDAP solution (implementation and level of application security functionality)
5. Review security implication of confirmed designs & what we know of Wave 2 & learning’s from vendor briefings - POC/Trust Model
6. Confirm HI & VI solution
7. Resolve iStrategy / Amazon overlap - Data/ETL
   Enterprise Data Model, Data Administration and ongoing ownership
8. Determine the Strategic Reporting approach
9. Consider contingencies for Solution Architectures (e.g. If there is no selection of a tool from the RFP tender as it is too expensive to implement etc)
10. Clarify Bank alignment and IFS implications

Potential Architecture items to review looking ahead…..

Higher Priority Architecture Focus….

11. Interface Architecture - Review and confirm assumptions in design for all interfaces between components (Wave 1 & Wave 2)
12. Define Architecture Opportunities / Options - e.g. additional funding becomes available
13. Produce Architecture slides for a “Roadshow”

Other Architecture Tasks….

14. Much time has been spent so far on defining the Wave 1 Solution Architecture Hypotheses. Need to finalise the Wave 2 Solution Architecture Hypotheses (e.g. particularly for Enhanced Offer / Strategic Desktop).
15. Consolidate and report of information gained from vendor briefings and follow on meetings.
16. Produce a document outlining the advantages to the business of the architecture (i.e. incorporating Plug In Architecture document recently produced)

13 Example: Reporting Firmness of Solution Design Hypotheses

Project	Firmness of Solution Design Hypotheses	Core Solutions Architecture Design Hypotheses
Strategic Advice Platform — Shape	Very Strong Hypothesis	Buy new FPT and integrate into new HI/VI architecture
Strategic Advice Platform — 360 Workbench Enhancements	Very Strong Hypothesis	Enhance existing 360 Workbench
Consolidated Database	Very Strong Hypothesis	Enhance Masterkey
i2M	Very Strong Hypothesis	Enhance Masterkey
Operational View — AKM (Distribution Desktop)	Very Strong Hypothesis	Siebel implementation
Operational View — ECV	Very Strong Hypothesis	Siebel implementation
Enhanced Offer — Flexiplan Project	Very Strong Hypothesis	Enhance existing Flexiplan systems
Enhanced Offer — Strategic Project	Strong Hypothesis	Build within Compass and related satellite systems
Enhanced Offer — Masterkey Project	Very Strong Hypothesis	Enhance existing Masterkey systems (Masterkey, MFND, Capsil)
Desktop — Campaign Management (Marketing Desktop)	Very Strong Hypothesis	Siebel implementation
Desktop — Call Centre/Admin	Significant Analysis Required	Leverage existing call centre systems or Siebel - (Wave 2/3 project)
Project Andes	Strong Hypothesis	Trade up into Compass / Capsil - (Wave 2/3 project)

The slide’s legend runs Not Started, Significant Analysis Required, Some more Analysis Required, Strong Hypothesis and Very Strong Hypothesis, with a struck-through row meaning Project not in Scope; the first, third and last states go unused on this slide.

14 Example: Presenting Options

Assessment Criteria	1 Client DB	2 R/T Slave	3 Joint	4 Master
Progression towards target (does it build towards the target architecture)	1	1	3	4
Level of throwaway/duplicated effort	1	1	3	4
Impact on users	3	3	2	1
Technical complexity	1	2	1	2
Delivery of a single source of truth	4	2	3	4
Risk - project and business	3	3	1	2
Time to market	3	3	3	3
Business benefits	3	2	3	4
Initial Cost	2	2	1	2
Ongoing Cost	1	1	3	4
Compliance/privacy	3	1	3	4
Flexibility	2	2	3	4
Resources	1	1	1	1
Life span of solution	2	2	3	4
Alignment with other projects/requirements (Enhanced Offer, Marketing, Con DB & Shape)	2	2	4	4
Total	32	28	37	47

Scale: Best 4, Worst 0

The slide’s two callouts:

Recommended Architectural solution

Outcome based on current business view of phased implementation needs. Will result in multiple update sources for initial release. Transition to EACV being single point of update in subsequent release(s).

15 Example: Tradeoff between Strategic options and delivery risk

• 6 weeks ago we presented our EACV Strawman Solution Architecture to the SAF - our hypothesis position on Integration Services was that we would design, build and deploy a set of reusable in house developed web services and back end adapters leveraging the Servicing POC as appropriate
• We also requested to undertake some more analysis where we could understand the requirement, and assess the relative merits of an integration services broker / hub software approach

16 Example: Educating the SAF on Definitions

Operational Data Store

• Integrated data within the operational environment
• The focus of the decision made from it is very immediate.
• Subject oriented
• Volatile – data is permanently added, updated and deleted
• Current valued – it stores the most recent data, preferably real time.
• Detailed data – at the same level of granularity as the operational systems with no additional aggregates or summaries.
• There is no longer term history (usually day/week/month worth of data)

Data Warehouse

• Consolidated view of enterprise data
• Optimised for reporting and analysis
• Data is structured for dynamic queries and analytics
• Subject oriented
• Read only
• It stores recent data as at end of last period (e.g. weekly or monthly)
• Data is stored at detailed level – supports ability to “drill down to lower level details.
• Time variant – data is stored for long-term periods.

Data Mart

• OLAP constructs containing a subset of enterprise data.
• Subject oriented
• Read only
• It stores recent data as at end of last period (e.g. weekly or monthly)
• Data is usually summarized
• Time variant – data is stored for long-term periods.

System of Record

• Operational and Transactional system
• Typically where data is managed.
• The bulk of our current information assets fall into this category.

An Operational Data Store can be further classified into three classes based on the timing requirement of the latest operational view:

• Class I — It is updated in synchronisation with the update to the legacy environment. The update appears in the legacy environment and seconds later the same update appears in the ODS.
• Class II — Store and forward approach. Update occurs in the legacy environment and its results are shipped to a separate file periodically every hour or so. The two environments are out of synchronization by an hour or two.
• Class III — It is one in which the store and forward technique is used, except that the synchronization to the Operational Data Store is done on a 24-hour or more basis.

17 Example: Project Brief for the Proof of Concept for Strategic Desktop

Statement of Purpose:

• Optimise the delivery of Servicing components across Amazon projects
• Confirm and prove up the Amazon servicing solution hypotheses and target architecture

In Scope:

• Access to Enquiry and switch transactions from Strategic Desktop to X and Y in real time
• Overall Security Design
• Servicing Components across the following Amazon projects:
  • Enhanced Offer Servicing Components
  • Strategic Desktop
  • ECV

Out of Scope:

• No other record systems besides X and Y will be accessed
• Enterprise Middleware (EAI)
• Siebel UAN capabilities
• Product switching between admin systems
• Product update transactions

Outcomes:

• Confirmed understanding of business servicing requirements
• Scope alignment between EO & Strategic Desktop
• Schedule alignment between EO & Strategic Desktop
• Recut project costs for EO and Strategic Desktop
• Defined target servicing architecture that EO & Strategic Desktop will build to
• Proof of concept built to verify target architecture:
  • Ability to access back end record keeping systems in real time
  • View, track and initiate workflow interactions

Key Hypotheses:

• Business has defined the servicing requirements to a level of detail that will ensure that this project will not be delayed once initiated
• It will be possible to re-use existing development environments to build and test the proof of concept
• The start date of the project may be delayed to ensure the availability of the complete set of Asset team resources
• An evaluation license can be obtained from IBM for installing MQ Serries and CICS connections on the mainframe

Major Project Milestones:

Phase	Duration
Project Initiation	2 weeks
Design	4 weeks
Build	5 weeks
Test	2 weeks

Major Project Risks:

• Access to BAU resources to perform analysis (This has not yet been negotiated with ADM BAU)
• Access to Asset development environments (This has not yet been negotiated with ADM BAU)
• Access to Siebel expertise to do the front end display

Project Leadership:

PCG: XXX
Project Leader: YYY

Team members:

• 1 x Project Manager,Architect (0.5 SD & 0.5 EO), Siebel (1), MFND(1), Capsil(1), CRMS(1), Gemini(1) & MQ(0.5), IBM GSA $100K - configure Mainframe MQ

Initiative Costs

$ZZZ

18 Example: Proposed Architecture for Proof of Concept

19 Example: Outcomes of POC

• POC has successfully demonstrated that a subset of technologies proposed for the integration servicing architecture can work as a whole in the Wealth Management environment.
• POC has achieved all the technical objectives and adhered to the guiding principles on which the integration framework was based upon and successfully validated.
• The actual effort spent on the development of integration was reduced as the degree of of complexity was lower than anticipated
• In addition, POC has expanded the scope and successfully addressed the following additional requirements:
  • Explore alternative way of accessing mainframe applications by using Siebel Portal Framework and HATS (Host Access Transaction Server) software
  • Conduct architecture analysis on the integration of other work-flow applications (Gemini, Staffware and Kust) by applying the lesson learnt from the POC.
• Proposed security design that would implement WMT security policy i.e. placing security as close to the data as possible, has been partially achieved. The token acquisition and validation have not been implemented as it would require system software changes on both AKM and CICS/DB2 environments. As there were no technical impediment in implementing the proposed approach, it was recommended that token acquisition and validation be progress as part of Amazon Wave 2 security.

20 Example: Key Issue uncovered as a result of running a POC

• Client Memory Usage error
  • It has come to light during performance testing phase of the POC that certain file downloads (between 5 and 10 megs) resulting in very high memory usage of around 350-400meg+ and this appears to be the combined result of the .Net code and the .net framework used for accessing web services.
  • If this cannot be resolved each Client Machine (Dialup machine) would require an allocation of 1 GB (Minimum) of free hard disk space to process large files.
• The POC team is currently investigating options in resolving this issue, including
  • The memory usage could possible be reduced by restructuring the Client Code to not load the entire file into memory before processing.
  • The memory usage within the .Net framework, however, is out of our control and could only be reduced by utilising a new architecture for the communication between VI Client and VI Coordinator; possibly dropping down a protocol level to HTTP or if absolutely necessary TCP Sockets. This would require endorsement by Architecture team)

21 Example: Lessons learnt from presenting to the SAF

Where SAF presentations have not gone smoothly

• Lack of content
• Lack of buy-in
• Mis-directed/incomplete syndication
• Ineffective peer review
• Not taking SAF along for the journey
• Optionsand evaluation not clear
• Not demonstrating that process has been followed
• Not demonstrating that analysis has been done
• Business drivers not agreed or understodd
• Lack of context

Lesson learnt/principle

• Revisit last presentation (if applicable) and outline progress of previous issues/agreements and the current state of the project/program/activity
• Position current presentation into the overall journey and clarify next steps. Explain the process you’re following.
• Provide references to Group position, if applicable.
• Detail what the implications of the decision being asked for would make for the project and for MLC.
• Consider cost implications for BAU.
• Relate the current activity/project/program to business strategy.
• Report progress of any hypothesis previously presented.
• Ensure that any syndication is relevant and specific.
• Highlight any dependencies/overlaps with other projects.
• Expect and prepare for a robust discussion at the SAF.
• Don’t pack too much into any one presentation - break the story up into manageable chuncks - especially if subject is complex.
• Don’t gloss over anything.

22 Example: Feedback from Roadshow …

• The majority of feedback for the SHAPE roadshow in Perth, Melbourne and Sydney was positive
• Questions 1-4 (total respondents in Perth, Melbourne & Sydney): Over 90% gained useful knowledge, viewed the session as worthwhile to attend, and indicated they would attend another similar Amazon information session.
• What was the most interesting part of the session? Total respondents indicated that the focus on architecture (13%) and integration (12%) was the most interesting aspect of the session. (20% ‘no comment’)
• Is there anything you would change about the session? Over 47% of total respondents did not comment/ indicated they would change nothing about the session, 19% indicated logistics
  • Sydney respondents indicated the venue was too small, that they could not see slides from the back
  • Perth respondents indicates that they would have liked more time for questions
  • All respondents expressed a preference for a break in the middle of the session
• Many respondents responded ‘no comment’ to many survey questions, indicative of the high quality of the presentation

23 The National’s adoption of SOA – Current Status

• SOA principles and web services deployed in pockets within the organisation
  • Most notably for a financial planning tool which exposes Web Services to third parties and J2EE/.NET integration.
• A wider adoption of SOA within one business unit was put on hold due to organisational restructure.
  • This would have involved the use of portal technology, composite applications, business process orchestration, and exposure of legacy system functionality as services to create an integrated servicing desktop.
• However, BPM technologies currently being investigated, with potential application in three business areas.
  • Potential to convert consumer lending fulfilment from bespoke functionality implemented on an obsolete platform to a workflow based implementation.
• Some parts of the business are adopting process modelling disciplines, which may prepare the organization for wider adoption of SOA in the future.
  • Drivers include faster product innovation and compliance (SOX, BASEL, IFRS)
• A new Enterprise Architecture has been defined based on SOA principles and adoption of BPM and EAI technologies
  • Fit for purpose front ends
  • Converged and shared sales and servicing functions
  • Product rules and features independent of core systems

Sources

• The deck, The Role of SOA within EA.ppt, 391 KB, twenty-three slides on the NAG corporate template. Its OLE metadata records creation on the 9th of March 2005, thirty-nine revisions totalling nearly eleven hours of editing, a last save on the 10th of July 2005 and 4,037 words — and its internal Title property still names the March conference, because the file began as a copy of that deck.
• Two sibling decks on the same backup volume mark the road between the March and August talks, neither reproduced here: a nine-slide cut of the March deck saved on the 13th of June 2005 for a Microsoft Architect Council session, and a thirty-six-slide “Putting SOA Into Perspective” assembled on the 15th of June 2005 for an ACS branch forum.
• The promise and pitfalls of implementing a Services Oriented Architecture, the March 2005 talk this one grew from.
• Services Oriented Architecture in a Retail Bank, the July 2006 talk that quotes slide 5’s four industry definitions again.
• Lessons Learnt from implementing and embedding an enterprise architecture team at National Wealth Management, the 2003 telling of the architecture practice this case study ran inside.