SOA Mainframe Service Architecture and Enablement Practices Best and Worst Practices

CSC Proprietary and Confidential 1/20/2016 10:03 AM PPT 2003_Toolkit_FMT.ppt 0
S424. Mainframe Service
Architecture and Enablement
Best and Worst Practices
• Michael Erichsen,
Chief Consultant, CSC
• Stockholm, 8 June 2011

Main points
• Why are we doing this?
– We have done integration projects in decades
– Service orientation can be a qualitative improvement
– The new aspect is open, standardized, loosely coupled interfaces
• Best practices are mostly found in the technicalities of service
enablement
– Case studies of seven different ways of doing it
• Best and worst practices are found in the service modelling and in the
implementation of models and architectures
– Some principles and patterns based on best practices
– Worst practices illustrated by ”anti-patterns” and research in what can go wrong
and how

A Conceptual, Technical View of Service Enablement

A Conceptual, Modelling View of Service Enablement

To Begin with the
Conclusion
SOA Mainframe Practices – Best and Worst

Why are we doing this?
Which problems are we trying to solve?
• The world is fast and messy
• Businesses and authorities need to
adapt very quickly to survive
• IT systems are generally
heterogeneous
• It is a mess - and it will remain so
• Service interfaces hope to remove
some of the mess – but also
introduce new kinds of mess

Reuse?
Oh no, not again!
• Software reuse is the process of
creating software systems from
existing software rather than
building software systems from
scratch
• First proposed in 1968
• Four dimensions:
– Abstraction
– Selection
• Classification
• Retrieval
• Exposition
– Specialization
– Integration

Reuse?
Promises, promises, promises…
• Over time
– Component Libraries with automated
customization
– Cut and paste of COBOL code
– Application Generators
– Object orientation
– Frameworks
– Service interfaces
• Reuse is not a technology, but a
culture
– Why not reward for reuse and
reusability?
• Otherwise a vendor might earn more
money by not reusing

Overarchitecting and Overengineering
• You need an enterprise
architecture, an enterprise data
model and good business process
descriptions to get the full business
and economic advantage of such a
project
• Reuse depends on a higher level
of abstraction
– But too many levels of abstraction
could mean that you can’t use it at all
in the first place

Extending or replacing Mainframe systems?
• The mainframe platform is
continuously under siege
– IBM's monopoly makes it difficult to
forge alliances
– The only practical solution to the age
problems seems to be offshoring
– The best way to protect the big
investments in mainframe systems is
to open them as equal partners in
modern architectures
• Not COBOL or Java/.Net, but strategy
and interfaces
– Using zSeries for SOA Infrastructure
interesting, but not unproblematic

The real economy of zIIP’s and zAAP's
• MIPS come cheaper, but they are
certainly not free
– Processor costs
– Other operation costs
• Investment in real storage
– Much more expensive than other
memory hardware
– Java Virtual Machines need very
large heap sizes for many
applications, including SOA
infrastructure like ESB’s and
BPMS’es
– Memory overcommit perhaps only
1,5 on new workloads?
• Calculate economy very carefully
to compare with other platforms

Lewis et al, SEI-CMM:
SMART: The Service-
Oriented Migration and
Reuse Technique

SMART: Defining a service
• A service is a coarse-grained, discoverable, and self-contained
software entity that interacts with applications and other services through
a loosely coupled, often asynchronous, message-based communication
model
– Quoted from Brown et al, Rational: Using Service-Oriented Architecture and
Component-Based Development to Build Web Service Applications

SMART: Defining a SOA
– A SOA is a collection of services with well-defined interfaces and a shared
communications model. A system or application is designed and implemented
to make use of these services
• 1. Service interfaces are added to existing enterprise information systems for
applications to use, while these systems remain unchanged for internal users
• 2. Service-specific code is written to provide functionality for applications to use
• 3. Services written by third parties and deployed elsewhere are used within applications.
– SOAs also offer the promise of enabling existing legacy systems to
expose their functionality as services, without making significant changes
to the legacy systems themselves
• This is one of the most attractive features of SOA to many organizations that do
not wish – and cannot afford – to walk away from their investment in legacy
systems or redevelop the same capabilities as services from scratch

Technical Best Practices:
Seven Case Studies

Seven Case Studies
1. A Tactical Service Enablement
2. A Tactical Service Enablement Evolving into Strategy
3. COBOL IMS in a large Scale SOA Environment
4. International, multilateral, heterogeneous and data replicating
5. XML Services over MQ
6. WebSphere ESB on z
7. Service Enablement of a Legacy Application Generator System

Case #1: A Tactical Service Enablement
• Back end system
– VSE, CICS, a 4GL and a non-relational data base
• The business need
– Update requests from business partners used in nightly batch runs
• No requirement for online updates of the mainframe system
• Web Services a mandatory protocol for communication
– Security required using TLS and X.509 certificates
– Not a general interface to the entire system, but a tactical solution for a single
demand
• Technical challenges
• VSE native SOAP and XML features did not really work for us
• No cryptographic hardware on the VSE box

Case #1: The Solution
The easiest solution was to
use a WebSphere
Application Server on
Windows
Daily updating Web Service
requests from partners
Weekly master data extracts
from mainframe for each
partner
Quarterly and semi-annually
control data extracted by
mainframe

Case #2: A Tactical Service Enablement
Evolving into a Strategic Solution after a successful
Proof-of-Concept
• Back end system
– An ”i-Case” tool generating COBOL in CICS at the back end and a fat Java
client at the front end with required runtimes and a proprietary communication
layer
– A generic callable interface to the application was already in place
– Online updates from business partners’ own systems
– Web Services a mandatory protocol
– Operation and field names had to be mediated between existing WSDL-
standard and COBOL restrictions

Case #2: Technical
Solution
CICS Web Support (now superseded
by Web Services for CICS)
An existing COBOL adapter to the
case tool generated code had to be
modified to a dynamic wrapper
Mapping definitions hand crafted

Case #2: A Proof of Concept
• A Proof of Concept was designed to explore possible problems like how
does
– Complexity and verbosity of the mandatory XML dialect fit with the tools
available?
– Internal security fit with this channel of connections?
– Digital certificates work in real life in this configuration?
– Service Enablement tools fit with exiting interfaces?
– Data from different parts of the back end system match to build a meaningful
response?
• The customer provided the XSD-definitions
• CSC built the adapter modules based on these and on the existing
structures in the legacy system

Case #2: Interface Design
• Discrepancies between XML data concepts and COBOL data concepts
had to be solved
• In real life it seems that no interface contract is perfect
• Data was defined in DB2, in COBOL, and in XML
• Optional and Variable Fields (0..1) (0..n) (0..*)
• Strings

Case #2: COBOL and XML Definitions
Type COBOL XML
String PIC X() String
Float COMP-1 Float
Double COMP-2 Double
Packed decimal COMP-3 Decimal
Binary COMP-4 Long, short, int
Date PIC X(10) in the application,
Content: 20061016
2000-01-12
2000-01-12T12:13:14Z
2000-03-04T23:00:00+03:00

Case #2: COBOL and XML Field Examples
Field COBOL XML
a 9(8) Date
b S9(5) unsignedInt totalDigits value="5"
c S9(11) COMP-3 Decimal totalDigits value="11"
fractionDigits value="2"
d S9(10) Double maxInclusive value="9999999999"
e x(30) String maxLength value="30"
f S9(8) unsignedInt totalDigits value="8"
g S9(4) String pattern value="[0-9]{4}"
h S9(10) Double maxInclusive value="9999999999"

Case #2 Version 2:
Back End Modernized,
Interface Simplified
Ongoing project to migrate case
tool to runtime-free COBOL and
Java to be maintained in Rational
Developer for z (RDz)
Back end web service interface
created bottom-up from
generated COBOL code using
RDz
Proprietary client communication
code changed to Web Services
for CICS
Front end client communication
using Web Services over HTTPS
with generated communication
code adapted to the WS4C
format

Case #3: COBOL IMS in a large scale
SOA Environment
– Back end system
• Large IMS COBOL system
– The business need
• Modernizing the entire heterogeneous enterprise portfolio based on SOA integration and
supporting a large number of protocols and formats
• Service enabling IMS systems with DB2 data bases
– Technical challenges
• Reusing existing web enablement skills and technology
• The new enterprise architecture regards all components on all platforms as both service
providers and service providers
– Must support both ingoing and outgoing Web Services requests

Simple interface to IMS
applications
Reusing large application
”motors”
OTMA (Open Transaction
Manager Access)
IMS Connect
WebSphere Application
Server with the AXIS
framework
Also coding new, outgoing
Web Services requests from
IMS COBOL applications

Case #3: The challenges
– There are limits on the protocol of 400.000-500.000 bytes
– Legacy applications used screen oriented logic
• Handled by adding new logic on top of legacy applications
– Existing web enablement coded in Visual Age for Java using the now obsolete
Record Framework
– Advantages
• The continuing existence of many skilled programmers and designers with deep
business knowledge
• Experience from an existing, well performing, and very successful web interface to the
IMS and DB2 systems

Case #4: International, Multilateral,
Heterogeneous and Data Replicating
• Back end system
– An IMS DB2 MQ system
– International, multilateral exchange of data, going from data base replication to
a service oriented architecture
– Many different data types with big variances
– Large binary data items
– Consistency checking between central and national data bases

Case #4: The Original
Solution
A Web Services Gateway
implemented as a simple
servlet on WebSphere
Application Server on z
MQ communication with IMS
COBOL programs handling
XML and Unicode, storing
data in DB2
Consistency checks became
too complicated and too
difficult to make well
performing
Local data base solution
superseded by direct service
requests to the central
system

Case #4: Taming the CPU Hog
• Technical Challenges
– IMS COBOL XML Unicode program was originally coded only for functionality
using XML PARSE, not for performance
– They used vast amounts of CPU
– A code review did not show anything unsound
– Transactions were profiled using Compuware STROBE to split CPU-usage into
handling of MQ, XML, Unicode and DB2

Case #4: Untuned system
0.50 CPU-second per transaction
MODULE
NAME
SECTION
NAME PROCEDURE/FUNCTION NAME CPU TIME Interpretation
.LELIB CEEBINIT CEEVGTSI GET A STACK INCREMENT 51.91
Runtime Storage
allocation
.COBLIB IGZCPAC
IGZCHXP COBOL LIBRARY
SUBROUTIN 31.69 XML
.LELIB CEEBINIT
CEEVOGTS XTND USR STK/DSA
OPLINK 7.10
Runtime Storage
allocation
CUNMUNI 1.64 Unicode
.SVC SVC 228 USER SVC 1.64 IMS
.LELIB CEEBINIT
CEEVOGSX XTND USR STK/DSA
OPLINK 1.09
Runtime Storage
allocation
RPS000 .55 The Program
RPS000 .55 The Program
.SVC SVC 120 GETMAIN/FREEMAIN .55
System Storage
allocation
.SVC SVC 013 TERMINATION .55 System

Case #4: COBOL Working Storage Reduced
1M to 100K
0.06 CPU-second per transaction
MODULE
NAME
SECTION
NAME PROCEDURE/FUNCTION NAME
CPU
TIME Interpretation
.LELIB CEEBINIT
CEEVGTSI GET A STACK
INCREMENT 36.17
Runtime Storage
allocation
.COBLIB IGZCPAC
SUBROUTINE 31.91 XML
.LELIB CEEBINIT
CEEVOGTS XTND USR STK/DSA
OPLINK 10.64
Runtime Storage
allocation
.XES IXLR1ALR ALTER W/RECORD REQUEST 4.26 SysPlex Services (DB2)
.SVC SVC 120 GETMAIN/FREEMAIN 4.26
System Storage
allocation
.SVC SVC 013 TERMINATION 2.13 System
.NUCLEUS CSVEXPR CONTENTS SUPERVISION 2.13 System
.LELIB CEEBINIT
CEEVOGSX XTND USR STK/DSA
OPLINK 2.13
Runtime Storage
allocation
.DB2 DSNIDM DATA MANAGEMENT DRIVER 2.13 DB2
.COBLIB IGZCPAC IGZCVMO VARIABLE LENGTH MOVE 2.13 COBOL Move

Case #4: Further tuning of LE/370
Measurements from the LE/370 Storage Report
Before After
Initial stack size: 131072 1048576
Increment stack size: 131072 102400
Largest used by any thread: 1010896 1007944
Number of segments
allocated: 3 1
Initial heap size: 32768 921600
Increment heap size: 32768 131072
Total heap storage used
(sugg. initial size): 818184 818152
Number of segments
allocated: 2 1
Initial anyheap size: 16384 32768
Increment anyheap size: 8192 8192
Total heap storage used
(sugg. initial size): 25648 26456
Number of segments
allocated: 2 1
• The important parameter is
“Number of segments allocated:”,
which should be 0 or 1
• Used parameters after tuning:
•ALL31=(ON),
STACK=(1M,100K,ANYWHERE,
KEEP,512K,128K),
HEAP=(900K,128K,ANYWHERE,
KEEP,512K,128K),
ANYHEAP=(32K,8K,ANYWHERE,
KEEP),
STORAGE=(NONE,NONE,NONE,
0K)

Case #4: Language Environment Parameters Tuned
0,03 CPU-second per transaction
MODULE
NAME
SECTION
NAME PROCEDURE/FUNCTION NAME CPU TIME Interpretation
.COBLIB IGZCPAC
SUBROUTINE 46.15 XML
.COMMON .COMMONX EXTENDED COMMON AREA 7.69 System
RPS000 .MQSRIES
CSQQSTUB QUIESCE AFT SYS LOG
ERR 5.13 MQ
CUNMUNI 00D1C0 5.13 Unicode
.SVC SVC 013 TERMINATION 5.13 System
.DB2 DSNXGRDS RDS ACCESS MODULE GENER 5.13 DB2
.DB2 DSNIDM DATA MANAGEMENT DRIVER 5.13 DB2
.DB2 DSNGEDM DATA MGT DBD/SKCT RTNS 5.13 DB2
RPS000 RPS000 00B380 2.56 The Program
.SVC SVC 228 USER SVC 2.56 System

Case #5: XML services over MQ
• Back end system
– A merger has created a heterogeneous environment with CICS systems, IMS
systems and Wintel systems
– A very big SOA program aims at having a new midrange industry system as the
front end and gradually replacing the legacy systems
– Service enabling CICS systems
– Generic callable interfaces to CICS and IMS systems are already in place
– MQ has been the integration channel for CICS and IMS for a number of years
– The enterprise service bus is implemented as Microsoft Biztalk
• Tools do not support SOAP over MQ, but SOAP over HTTP and XML over MQ

A modified Web Services for
CICS implementation
Reuse existing Biztalk tooling
Use RDz tooling to generate
WSBIND files for the existing
callable interface

Case #5: Pipeline Config File
<?xml version="1.0" encoding="EBCDIC-CP-DK"?>
<provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/software/htp/cics/pipeline
provider.xsd ">
<service>
<service_handler_list>
<handler>
<program>CSCHDL01</program>
<handler_parameter_list />
</handler>
</service_handler_list>
<terminal_handler>
<cics_soap_1.1_handler/>
</terminal_handler>
</service>
<apphandler>DFHPITP</apphandler>
</provider_pipeline>

Case #5: Dummy SOAP Header Handler Program
GET CONTAINER(PI-DFHFUNCTION)
IF PI-RECEIVE-REQUEST THEN
GET CONTAINER(PI-DFHREQUEST)
Remove existing <?XML tag
Add a dummy SOAP envelope around the payload
PUT CONTAINER(PI-DFHREQUEST)
DELETE CONTAINER(PI-DFHRESPONSE)
ELSE IF PI-SEND-RESPONSE THEN
GET CONTAINER(PI-DFHRESPONSE)
add <?XML tag
Test each tag in Response-Data to find if it starts with <soap or
</soap and then remove
PUT CONTAINER(PI-DFHRESPONSE)
Move "text/xml" to MEDIATYPE-DATA
PUT CONTAINER('DFHMEDIATYPE')

Case #6: WebSphere ESB on z
• Back end system
– An IMS COBOL MQ system
– Integration between applications on z, Oracle/Unix and Wintel using Web
Services and MQ
– The need for real storage is much larger for JVM’s than for traditional workload
– Recycling JVM’s costs hundreds of MIPS in quite extended periods
• Even though most of it is offloaded to z**P processors
• Z**P processors are not free either

Case #6: WebSphere
ESB on z Challenges
After a long quiet night the
first transactions in the
morning could take minutes
causing client timeouts
Difficult to monitor –
compared to CICS, IMS, MQ
etc.
Workload Manager policies
quite complicated

Case #7: Service Enablement of a Legacy
Application Generator System
• Back end system
– CICS, DB2, originally coded in the 4GL CSP
– A 20 year old legacy application still represents the core of the business and a
long-term investment
– Back office and staff can use web and cloud applications, which need access to
the core system and its data, both inquiries and updates
– The application was coded in CSP and still has a 3270 user interface

Web Services for CICS
developed using EGL tooling
in Rational Business
Developer (RBD) and RDz
The first service was used by
a web form

developed using EGL tooling
in Rational Business
Developer (RBD) and RDz
The first service was used by
a web form
The second service was
used by a Salesforce cloud
application
The integration from
Salesforce was done using
a Cast Iron SOA appliance

• The first service with a single operation just updated a single field in the
core data base
– The front end is a simple web form, which calls a web service
– Very easy to implement – took 20 minutes to code and generate
• The second service with half a dozen operations ran into all kinds of
technical problems

Case #7: Modelling the Service
• Describe the existing user interaction with the 3270 application
• Model this as a business process
• Describe the operations needed in the new service to support this
process
• Define the programs needed to implement the operations and the
interface as message structures

Case #7: Restrictions when developing
• If you need to have a structure as a response from an EGL Web Service
for CICS the request must be the same structure (Input == output)
• A configuration file called the “deployment descriptor” must not have the
same name as any EGL program
– RBD will quietly generate a COBOL program with the name of the deployment
descriptor to overwrite the legitimate program just in case you also wanted to
have an outgoing web services request
• The predecessors to EGL were COBOL-like in their structures and
culture, while EGL is java-like in its structures and culture
– This difference can lead to great difficulties when service enabling legacy
programs

• Do you have arrays in the externally exposed structure definition in the
service programs?
– Then the structure needs to be an unstructured record to have arrays generated
correctly into the WSDL document
– The field definitions must not be preceded by level numbers
• Otherwise the array will be “flattened” with all occurrences of each subfield
• {a1 a2 a3 b1 b2 b3 c1 c2 c3} in stead of {a1 b1 c1 a2 b2 c2 a3 b3 c3}
– Note that unstructured records are dynamic
• If you do not allocate them yourself they will be empty or even null

• A static array like this:
01 MYARRAY ARRAYRECORD[10];
Is allocated in storage like a COBOL program would
• A dynamic array, distinguished by not having level numbers:
myArray arrayRecord[10];
Is not allocated, but must be explicitly defined to avoid null pointers
• EGL generation for COBOL does not support multidimensional, dynamic
arrays
• All this is not considered an error, but a design, by IBM, even
though it is deeply unintuitive for a legacy programmer

Summing up the case studies
• Mainframe service enablement is probably our most important area of
mainframe application development in recent years
• There are many ways to service enable an existing application
• Use your existing skills, tools and methodologies where you can
• Make the service interface completely hide what is behind it
• Remember:
– To be reusable it has to usable in the first place!

Best and Worst Practices
in Service Modelling and
Architecture

Best and Worst
Practices
•Mark Skilton, CSC: Three simple
rules for definition what is a Service
are
•Forrester: North American SOA
Systems Integrators
•Gartner: The 13 least wanted
•Ang, Cherbakov & Ibrahim, IBM:
SOA Antipatterns
•Tarak Modi, Unisys: SOA
Antipatterns
•IBM on SOA Governance
Nice to have research to quote
Rather than admitting your own
mistakes
"The secret to creativity is knowing
how to hide your sources.“
(Albert Einstein)

Mark Skilton, CSC:
Service Oriented
Architecture

Mark Skilton, CSC: Service Oriented Architecture
• Three simple rules for definition
what a Service is
• Five key areas to consider when
looking at the granularity of
business and IT services
• Three key operating principles of
SOA/POA underpin these choices

Mark Skilton, CSC:
Three simple rules for definition what a Service is
• It is strategic
– The capability is critical to your organisation
• Composable
– The service can be run in its own and be combined with other services to build
new services not originally specified
• Rule of Three
– If an interface and/or message is used in more than three systems

Mark Skilton, CSC:
Five key areas to Consider when looking at the
Granularity of Business and IT Services
• Performance and size
– Neither too big nor too small
• Transactionality and state
– This audience should know all about
that!
• Business suitability
– One operation for one business step
• Safe operations
– Read only or reentrant
• Idempotency of operations
– Can be called again without
changing the result

Mark Skilton, CSC:
Three key operating principles of SOA/POA
underpin these choices
• Process Integrity
– Active
– Safe
– Idempotent
• Data Integrity
– Transactionality and states
– Data Synchronisation
– Logic
• Security Integrity
– Security policies, processes and
technologies

Forrester:
North American SOA
Systems Integrators

Forrester: North American SOA Systems Integrators
• In a typical project that uses SOA strategically, there are typically five
steps that organizations need to follow to successfully complete the
project
1. Develop a future state for the business to evolve toward
2. Map existing business services to current business processes
3. Map business services to IT solutions
4. Map IT assets to IT solutions
5. Design SOA governance and infrastructure

Gartner:
The 13 Least Wanted

Gartner: The Thirteen Least Wanted
1. Starting too big
2. Starting in the wrong place
3. Leaving SOA to the "techies“
4. Underestimating the technical
(and infrastructure) issues
5. Assuming that everyone thinks
like you
6. Selling SOA before you're ready
7. Choosing anarchy or
dictatorship as leadership styles
8. Excessive centralization
9. Irrational SOA exuberance
10. Forgetting to consider the data
11. "Not invented here" syndrome
12. Allowing nonshareable services
to proliferate
13. "I already have 200 services,
now what?”

Ang, Cherbakov &
Ibrahim, IBM:
SOA Antipatterns

Patterns and Anti-Patterns
• Patterns are a popular way of
illustrating best practices
– SOA Patterns are used very much in
discussions and literature
• Anti-patterns are being used more
and more to slow down the hype

Ang, Cherbakov & Ibrahim, IBM:
SOA Antipatterns (1)
• Adoption
– Technology Bandwagon
– So, What’s New?
– The Big Bang
• Design
– Blob
– Poltergeists
• Structure
– Spaghetti code
– Stovepipe systems

• Technology
– Wolf ticket
– Continuous obsolescence
• Reuse
– Cut-and-paste
– Golden hammer

• Identification & Design
– Web service = SOA
– The Silo Approach
– Misbehaving Registries
• Realization
– Chatty Services
– Point-to-point Services
– Component-less Services

Tarak Modi, Unisys:
SOA Antipatterns

Tarak Modi, Unisys: SOA Antipatterns (1)
• The "Same Old, Same Old"
Phenomenon
• The "Big Bang" Approach
• Service Fiefdoms

Tarak Modi, Unisys: SOA Antipatterns (2)
• Technophilia
• Bloated Services
• Anorexic Services
• Hyper Brokerage

IBM on SOA Governance

• "Wild West" or “Rogue” Services
– Extremely difficult to gain control over
• "Duplicated” Services
– Superficially effective but limited real
savings
• "Shelfware” Services
– A waste of resource, won’t deliver
benefits

• Unsecure Services
– Limits service use and business
opportunities
• Rigid Services
– Roadblock to agile, flexible business
processes
• Ineffective Service Management
– Services must be managed as
resources

A few more Issues

Carsten Svensson, EEI: The Cost of SOA
• Cost of SOA =
(Cost of Data Complexity +
Cost of Service Complexity +
Cost of Process Complexity +
Enabling Technology Solution)

Performance
0
500
1000
1500
2000
2500
1 3 5 7 9 11 13 15 17 19 21 23
Online
Self-service
Online & Batch
The daily CPU consumption pattern
will change
If you only run an online workload
If you run online and a lot of batch
If you run in a service enabled
environment, where services are
used by a self service web application
If you rely on a batch window it might
collide with the self service window
after dinner, when the kids are in bed

The culture clash between Java and COBOL
• COBOL was born to optimize
administrative computing
– Java and XML was born for dynamic
interfaces
– It takes a lot of sweat to reconcile
them
• Data in COBOL working storage
allocated implicitly by the compiler
– Data in Java must be allocated
explicitly by the programmer

To Summarize
• There are many ways to integrate mainframe systems into service
oriented architectures
– A lot of best practices are to be found in the technical solutions
• You need a close cooperation between business stakeholders, architects,
developers and technologists to make it work
– The worst practices are found when application, design and architecture on one
hand does not take the requirements of the technologies and the infrastructure
seriously
• All the mistakes have already been made and are extensively
documented

THANK YOU

SOA Mainframe Service Architecture and Enablement Practices Best and Worst Practices

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to SOA Mainframe Service Architecture and Enablement Practices Best and Worst Practices

Similar to SOA Mainframe Service Architecture and Enablement Practices Best and Worst Practices (20)

More from Michael Erichsen

More from Michael Erichsen (13)

Recently uploaded

Recently uploaded (20)

SOA Mainframe Service Architecture and Enablement Practices Best and Worst Practices