top of page

Traditional Business and IT solutions versus SOA Business and IT solutions

  • Writer: Mark Skilton
    Mark Skilton
  • Jan 14, 2008
  • 13 min read

A POLDAT perspective on Traditional IT Business Solutions versus SOA Style IT Business Solutions

The “10 things” you need to know about SOA

  1. SOA is a architectural design style that affects the way business processes are designed and the design and use of Information Technology.

  2. SOA is predominately a architectural design style for distributed heterogeneous business applications over a federated network. SOA is primarily concerned with achieving three things:

  3. Decoupling the functional logic from the applications and their data so that you can use the logic like a “service” e.g. get_list_of_Customer_Orders_>100Value

  4. Encapsulating the functional logic so that it can be independently used from the applications and data that have encoded that logic. This is usually by defining a meta-language, for example WSDL or XML or BPEL to describe the logic and its operations. This then enables the following:

  5. Composition of functional logic into IT services and Business services that are used by different User Interfaces (UI) as consumers of these services

  6. The business case for SOA is never defined in technology terms, but in the language of business value BUT with specific service-oriented goals. The Business solution is then delivered based on Architectural design principles that are SOA centric. The SOA oriented business case sees to emphasis three things from traditional IT solution business cases:

  7. Cost reduction of business processes e.g. automation and staff efficiencies

  8. Speed of flexibility / business response to change – the ability to change business processes faster; other up new business products and services faster

  9. Reuse - it is the intention of an SOA style project to enable business to create shared business activities , self service and other ways of enabling the business to maximise economies of scale

  10. SOA design style does not work with traditional IT POLDAT work products. This is because

  11. SOA is mainly a set of IT design standards and specific technology components that follow a set of service oriented principles. These can be summarised into five things

  12. Protocol standards for exchanges messages between heterogeneous systems

  13. Syntax standards for the definition of the content and language of what the

  14. API standards for the specific program interface components that will be used to execute the serv

  15. State management for synchronous and asynchronous access to services. Specifically how the state of a service may be a shared state requiring orchestration.

  16. Service Metadata standards for how the service contract

  17. SOA needs a viable SOA vision and SOA reference architecture that defines the benefits case and the specific things that make the solution Service-oriented

  18. The Commercial case for SOA does not existing inside a project. The case for SOA has to be funded by the Organisation’s operating budget. The reuse of SOA capabilities exists outside a project. (A project may deliver SOA for a cost but reuse is a program and organisational issue).

  19. SOA needs Governance in order to control maverick behaviour and variations of service oriented standards use to prevent “today’s SOA from becoming tomorrow’s Legacy (Quote from Zapthink.com). Governance needs three forms:

  20. Organisational governance: an Architectural governance office is in place for enterprise architect management

  21. Environmental and SOA lifecycle governance: a set of tools to

  22. Security governance: a set of security controls and technology components are in place and integrated into the SOA solution.

  23. Performance and scalability can be achieved with SOA using the right design patterns and technology components. The size of the service payload, speed of SLA response and volume model needs to be integrated into the choice of technology solution.

  24. Service Portfolio Management is in place to align the overall business and IT goals with the SOA style assets that are created by SOA style projects

When not to use or proceed with an SOA style as a Solution

  1. The integration and applications are specialist and specific to just one business area. There is no demand for reuse and is only supported by specialist staff and vendors. (there is some value is enabling changes to this solution using SOA techniques)

  2. The solution is a bespoke one-off

  3. The volume of data and transactions have not been considered in the choice of technology solution

  4. The sizing for SOA design have not be done

  5. Where there is many access paths and non-determinant queries such as using a Data warehouse hypercube for complex data analysis and multiple access path queries. In such a situation the multiple permutations of possible service calls makes it infeasible to be defined in service contracts

  6. The event complexity does not led it self to steady state service contract design – would require too many dynamic changes to the service contract

  7. Project Management and Program do not have SOA experience and skills

  8. There is no management skills to deliver an SOA style project

  9. Architecture resources do not have SOA experience and skills

  10. There is no design and delivery skills to deliver a SOA style project

  11. Support structure to run an SOA style project is missing

  12. The Technology has not been fully evaluated for the intend SOA purpose

  13. There is no SOA reference architecture standards

  14. No standards for service integration design in place

  15. There is no basis for standards reuse

  16. No commercial contract requirements of specific financial budget allocated to deliver SOA style benefits in the first place

  17. So why an how would the benefits need to be realised? How would the project be funded?

Critical enablers for a Delivery Assurance Review of an SOA project and program

  • Are their the skills in place to do SOA?

  • Is there SOA raining in place ?

  • Is the right level and skills for an SOA style DA review available ?

  • What are the documents in SOA ?

  • See Catalyst Service Model

  • What is different about SOA ?

  • See “Understanding SOA” White Paper Jan 2008

  • See “SOA Beef Bourguignon” slide briefing Jan 2008

  • What is the SOA checklist by each phase of a project ?

  • See Catalyst Service Model and workflow

While SOA is the prevailing Enterprise Architecture style of the moment there are a number of considerations in establishing successful SOA engagement and maintaining these. Overall SOA is a set of design principles and artefacts that can be applied to any solution situation to create service-orientation in the way the solution is used. I have listed a few observations that can be characterised as potential factors that can affect SOA Delivery

OBSERVATION: SOA as Class A artefacts

SOA does create new class A deliverables that become part of the project and extension of the Enterprise Architecture Model beyond the life of any one individual project. This is a challenge for most traditional old style design practice not recognised that this is the case and can be compounded by the continuation of old style process, data , application and technology model views. SOA does work and there are many projects to support this but SOA does not work if the project team and organisation do not use the SOA artefacts properly.

The Class A artefacts (Service Portfolio, Service Contract, Service Interface Design Specification ) need to be defined correctly and used by the development and analyst teams correctly. In some respect SOA sets in motion an expectation that technology is “plug and play” but is still defined in these “paper based” models and so needs to be administered to ensure it remains that way otherwise new projects come along and yesterdays SOA becomes out-of-date and reuse is lost. This supports the argument of managed integration services and removing the integration problem from the user with tools that hide this complexity. Solutions in BPM and Portals and XML style composition tools are moving that way.

KEY SOA PROJECT DESIGN ARCHITECTURAL PRINCIPLES:

  • An SOA project must have SOA work products

  • The Service Model

  • Service portfolio

  • Service contract

  • Logical canonical data model

  • … (See published Catalyst Service Model Work Products)

RATIONALE

  • Because the outputs of the project must be reusable outside the project lifecycle – they are built for “reuse”

  • Because the design of the project code, logic and data must follow open standards and service design principles agnostic from the technical system and specifications.

OBSERVATION: Big bang versus incremental

There has been attempts to do too much scope in moving to the SOA style and projects have lost control. Evidence of where SOA works is in approaching specific problems and building incrementally. An important aspect here is setting domain controls and “street level or district level boundaries”. The logic rules for this are not defined currently from what I have seen and read to-date.

KEY SOA PROJECT DESIGN ARCHITECTUAL PRINCIPLES:

  • The project must split the solution into technical and business process scope for each release of the project

  • The technical releases are identified as a collection of one or more “services”. Technical releases are they delivered as releases of “services” NOT of Technology versions and Platforms. (The technology infrastructure MUST have been built and tested BEFORE the commencement of the SOA project.(or time allowed for the Proof of Technology (POT) (that the technology and standards choose will work together to enable a SOA solution to be built) and Proof of concept (POC) (that the service orientation solution will work) to have been completed))

  • The business process threads describing the scope of the project are defined by a business process model that has been split into

RATIONALE

  • Because the construction of IT is still based on platforms of applications, servers, networks and routing, circuit devices. The ownership of these technologies are spread across different functional responsibility groups.

  • SOA creates “services” that are hosted on one or more of these platforms and devices. These “services” are designed to work homogenously with specific platforms, standards and technologies that will host and use these “services” - typically passing across functional business areas and applications and networks that are themselves heterogeneous.

  • Ownership of SOA “services” needs to be recognised by these owners so that the SOA concepts and homogeneity is preserved – and that the “services” are reused and managed

  • Changing the entire IT landscape is simply not feasible in most cases. A co-existence and migration strategy is needed to move legacy systems or to introduce new solutions.

OBSERVATION: Standards Maturity and experience

I do meet senior technologists and Research Analysts who have the view that Web Services WS* standard is “application blind”, is “heavy payload” and not fully working currently. The UDDI situation of incomplete mapping has not helped this matter much either and the perception atleast that this form of registry has not had a huge uptake. An alternative working view I have seen is still using SOA principles but using the APIs of the vendor as the “translation and transformation point” of the service rather than the WS message level interoperability. The view here is that the Vendors can be held accountable if their API solution e.g. SOAP Adapter or Java Adapter does not work. This is technically not true SOA as its bound to the technology implementation of that API but atleast it’s a pragmatic one.

Conversely you can argue that the standards in Portlets, REST and Web Services / XML have been very successful and wide spread and with the emergence of Web 2.0 that uses these technologies you kind of can see that this has moved on further into compositional tools. The challenge for large monolithic organisations like CSC is to be able to be agile enough to move at this pace.

KEY SOA PROJECT DESIGN ARCHITECTUAL PRINCIPLES:

  • There must be a vision and technology architecture and business process and organisational skills and resources roadmap plan with supporting standards of how to reach the SOA solution. It must be possible to measure the value of the SOA vision and any SOA style project that delivers to that vision

  • The CIO or equivalent must have identified business and IT benefits in the operation budget and plan or have allocated a funded to support the SOA initiative

  • The Business benefits of SOA have been quantified and defined clearly must be within the organisation outside of the project or program of projects

  • The specific standards of technology need to be clearly defined for the SOA style design, notably:

  • Business Process model notation

  • Technology development framework notation e.g. JAVA, .NET

  • Message level protocol notation e.g. HTTP, SOAP,

  • Information payload level protocol notation e.g. XML

  • Service Contract specification meta data notation e.g. WSDL, XML,

  • API specification and transformation notations e.g. AJAX, Portlet JSR…, XPATH, ..

  • A set of rules defining “what is the criteria for a service” that reflects the type of business process that can be enabled as a business “service” and the type of IT components that can be enabled as an IT “service” should be defined and clearly understood.

RATIONALE

  • Because the SOA style solution is based on a set of commonly agreed standards in protocols, syntax and exchange rules

  • This is to enable heterogeneous systems to “talk” to one another in a homogenous way

  • This is to enable the logic functions of a system to be described and defined in a commonly understandable notation to enable homogenous reading and use of that “service”

  • The term “granularity” refers to the size, scope and span of the logic function that has been described by a Service contract

  • Too large a scope (too many operations and large payload message …) can cause performance and scalability issues. It can also loose the

Integration bus complexity

While all Vendors are moving to a Service oriented model (unbundling their technology stack into modules; supporting an n-tier style framework and encapsulating their functional logic for reuse and composition etc). The use of ESB integration Buses has proven to be complex and difficult to verify its operational capabilities (“what it said on the tin does not work in practice” e.g. full API translation capabilities, performance issues and roll back situation).

This does not mean that they do not work and CSC and other SIs have made a considerable revenue streams from this one of the prevailing technologies for cross system to system application level integration. The issue is that apart from large scale programs the ESB route is complex and expensive. The response is to take different paths to SOA by following the Service design paradigm using smaller solutions to compose services that are less middleware intensive.

A second by product of this technology readiness issue is the problem of some projects hitting integration problems without fully testing the POT and POC of the technology before embarking on the pilot or project.

Skills and level of education

The new in take of staff shows an increasing awareness of SOA and the orientation towards this style. The main problem is incumbent skills of staff who do not have the level of design skills to approach the solution in a service oriented way. This approach needs to recognise the combination of process, data and functional modelling as composite tasks that are related to each other. Current traditional roles tend to split up the Business Analyst, data analysts and Technical architect creating artificial boundaries that need to be integrated in a service specification. The role of the Fusion methodology for example and Architecture governance is key to making this work.

Business case understanding and attitude

Many sales staff still struggle with selling SOA when this can be accomplished by selling the business benefits of services and implement the solution using service oriented principles and practices. The attitude seems to move towards older systems integration views and resourcing models that body shop and create many “one off” activities to fix functional point solution themes like ERP, data, process, Integration and don’t seek to exploit shared services, composition and new service oriented models. Business benefits of SOA are explained in terms of flexibility, rationalisation, agility of business which are enables through SOA designs. Traditional styles can also have these goals but the solutions create locked in logic and limited reuse across business boundaries; replicated licences and more expensive longer term problems for TCO and support. The net effect of this is that the benefits of SOA are not defined and since SOA integrated non-functionals into its service models and notably in the service specifications the value of SOA is not managed and becomes a self fulfilling prophecy.

Organisational boundaries

Many internal and external boundaries in IT organisations create issues around a common vision and approach to reuse and service orientation. The exchange of designs and skills between LoS does not follow the necessary integration approach that a common services framework needs. This never more so evident between architecture and project management or between the functional roles of designers.

Consistent Design Process Model / test approach

A key to SOA success is a consistent and repeatable design process. This is advocated by many Research analysts and is often the source of when SOA (or traditional ) design breaks down. For example the flow between requirements and modular releases needs a test strategy and test approach that supports process oriented test styles for SOA.

Commercial attitude

The commercial contracts often do not recognise the IPR and Reuse aspects of the solution and tend to mitigate against SOA benefits by controlled to tight timelines and encouraging payments by deliverables rather than reuse.

Project Management attitude

Traditional project management centralises and seeks to control architectural design in many ways. A net result observed in many cases is “Project Management defined solution architecture” rather than architectural led design. The reuse and longevity of Service artefacts is not known to most project management resources who see this as a background task to architecture design rather than being used to help governance the program for reuse. Of all the concerns this is probably one of the biggest problem areas currently. Traditional project management and governance are separated from architecture design methodologies. In SOA this is not the case and needs to be integrated.

Training and uptake of certifications

There are training and certification courses for SOA from the Vendors but this is not mandatory for many CSC practitioners. There is a Virtual SOA Training Academy which is starting to address this but currently not aware of any specific detailed Catalyst SOA training in place yet. The Service model is still in progress and I understand that post April this year there should be enough of the Catalyst SOA model to be “trainable”. This is a good development and one that will help address some of the challenges.

Audit Assurance skills

In the UK Solution Directors group there are concerns raised with the quality of solutions coming through in the current Red review and audit practice skills observed in bid phases and Solution/Account reviews. The root of the problem is the inability and skill set of the Solution Designers and the reviewers to define what the boundaries and specific deliverables are that concerns service orientation. This is compounded by the perception that there is a joined up “Solution community” that own the Solution who have a set of templates that define what the Solution specification and how it is to be ordered properly.

Work is currently underway to create a Quality Process by the Solution Directors group to provide guidance about what a “complete” solution needed to contain in order to be robust enough and included in this is Service oriented deliverables and check lists.

Where next

The movement in the market and the development of SOA engagement offering is moving towards refresh or new business models such as the recent trend in India outsourcers that are looking to build and own the Solution and infrastructure and then charge it back on a pay-per-use basis. (See link attached http://www.ft.com/cms/s/0/1d995582-c06e-11dc-b0b7-0000779fd2ac.html?nclick_check=1

) This fits recent conversations I have witnessed in CSC around the SOA Foundation services development and more recently the possible realisation in GTS /GIS of the need for SOA style factory services to compete in bids (triggered by recent high profile bid losses) The challenge in the UK and probably globally is the lines of service and the disciplines necessary to implement SOA at the planning and design time.

Mark Skilton

Jan 2008

 
 
 

Comments


Featured Posts
Recent Posts
Archive
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

Mark Skilton    Copyright 2019  ©

  • White Twitter Icon
  • White Facebook Icon
  • White LinkedIn Icon
  • White YouTube Icon
  • White LinkedIn Icon
bottom of page