TeamStation AI System Report LATAM IT Salaries 2024
Case study experiences with services-oriented sap
1. CASE STUDY:
Experiences with Services-Oriented
Services-
Solutions Architecture Process
S l i A hi P
Presenting: John Bernhard - Enterprise Architect
[Bernhard Enterprise Architectures Pty Ltd]
2. Services-
Services-Oriented Solutions Architecture Process
Agenda
A d
Overview
High Level Process Overview & Artefacts
Business Architecture Process (BAP)
Solutions Architecture Process (SAP)
Technical presentation of the Solutions Architecture Process
Activity based costing (ABC) on component level
Lessons learned
Questions?
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 2
3. Services-
Services-Oriented Solutions Architecture Process
Overview
O i
Then
Solutions Architecture produced by Vendor… or by PM, BA or
Systems Analyst
Software development outsourced by the companies
Now
Companies wants ownership & retention of Architecture IP
Companies wants to be in the position of making Development
partners more accountable (previously all solution design and
development cost were a black box)
p )
Companies aspirations are to develop solutions based on re-
re-
usable Service-oriented software assets
Service-
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 3
6. Services-
Services-Oriented Solutions Architecture Process
Business Architecture Process (BAP)
Definition:
Business Architecture: a d i ti of the anatomy of th b i
B i A hit t depiction f th t f the business in
i
terms of its value streams or business processes. This blueprint is depicted
as a top-down, hierarchical decomposition of business processes. Think of it
top-
as a Bill of Processes - which is to a e te p se as t e b o materials
o ocesses c s an enterprise the bill of ate a s
(BOM) is to an airplane.
Objectives:
At a business level - a tool for understanding and optimising the structure
of a business and how it delivers customer value. It allows you to
understand the decomposition of the business in a diagrammatic form and
p g
helps you see how all the parts fit together to form a whole
At a solutions level - a tool for identifying and optimising a set of business
components that can be realised by corresponding technology/software
components such as web services and messages (SOA and EDA Services)
t h b i d d S i )
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 6
7. Services-
Services-Oriented Solutions Architecture Process
Business Architecture Process (BAP)
B i A hit t P
How do we elicit the “Business architecture"?
1. Ideally - work-shopping with business stakeholders in a top down fashion
work-
using a mind-set that is purely focused on the business processes, elementary
mind-
business functions, events and people that deliver customer value rather than
b i f i d l h d li l h h
on the underlying systems. This approach can be used to map out both current
and future state views of the business; but is typically used to define what an
optimised future state business might look like.
2. Practically - synthesizing an optimal set of business components (and hence
services) based on a combination of top-down business process analysis and
top-
bottom-
bottom-up functional analysis using as input things like: business requirements,
business/functional use cases, business rules domain models activity
cases rules, models,
diagrams showing flow-of-control and co-ordination among the use cases.
flow-of- co-
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 7
8. Services-
Services-Oriented Solutions Architecture Process
Business Architecture Process (BAP)
Notations Definition:
D fi iti
A business process is a set of linked
Business Unit
Business Unit or Business Domain
activities that create value by transforming
an input into a more valuable output. Both
input and output can b artefacts and/or
i t d t t be t f t d/
Business
Business Process
information and the transformation can be
performed by human actors, machines, or
Process
both.
Activity Activity ithi
A ti it within a B i
Business P
Process
A business process can be decomposed
into several sub-processes, which have
sub-
Elementary
Elementary Business Function
their own attributes, but also contribute to
achieving the goal of the super-process.
g g super-p
p
Business
Function
Activities are parts of the business
Business
Object Business Object process that do not include any decision
making and thus are not worth
decomposing (although decomposition
would be possible), such as "Answer the
Business
Interface
Business Interface
phone", "produce an invoice".
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 8
9. Services-
Services-Oriented Solutions Architecture Process
Business Architecture Process (BAP)
Definition: Definition:
An elementary Business Function A Business Interface is a boundary
across which two independent business
is a specific unit of work. To be components (being Business process,
p ( g p ,
considered elementary, a function must
id d l f i elementary business function or business
be the smallest unit of work that either object) meet and act on or communicate
retrieves or changes information. with each other.
A Business Object is a physical or A Business Component describes
p
logical object of significance to a conceptually the components which makes
up the overall business architecture, i.e.
business; for example, a department, a business process, elementary business
business application, a business User, an function, business object. The business
External Business application
application. architecture is otherwise known as:
A business object is analogous to a class Business Component Architecture
in object-oriented terminology. A Business Component Interface
describes the interface requirements for
the business component
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 9
11. Services-
Services-Oriented Solutions Architecture Process
Business Architecture Process (BAP)
Business Architecture view - Airline Club Business Unit
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 11
14. Services-
Services-Oriented Solutions Architecture Process
Solutions Architecture Process (SAP)
S l ti A hit t P
Characteristics:
Collaborative up-front engagement of architecture stakeholders
up-
p g g
Structured but flexible – tailored to characteristics of project
Rapid process based on up-front planning & intensive workshops
up-
Driven by the Solutions Architect, but co-ordinated by the Project
co-
Manager
Form of inputs flexible – dependent on type of project e.g. web-based
web-
SOA vs package implementation
Architecture streams are based on the Component Architecture (First
draft)
Objectives:
Formalisation of a structured Solutions Architecture process primarily
F li ti f t t d S l ti A hit t i il
for Software development projects (esp. those based on SOA)
Solutions Architecture excellence through embedding of our
Enterprise Architecture principles & framework into solution delivery
to ensure we deliver optimal, efficient and cost effective solutions
optimal
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 14
17. Services-
Services-Oriented Solutions Architecture Process
Activity Based Costing (ABC) on component level
Traditionally:
Traditionally vendors produced proposals and costing on the basis of
business and functional requirements documents produced by a
company
Vendor proposals contained solution approach and high level costing
based on th i software development methodology
b d their ft d l t th d l
Difficult to ascertain where the actual cost lies during the
development phase
Lack of granular component-level costing makes it difficult to identify
component-
potential savings
i l i
Architecture IP stays with the vendor – not the company
Benefits from ABC:
Components list automatically derived from component model [using
Sparx Enterprise Architect]
Traceability of costs to solution components
Identification of cost anomalies and optimisations
A degree of plug-and-play i.e. flexibility around who develops what
plug-and-
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 17
18. Services-
Services-Oriented Solutions Architecture Process
Lessons L
L Learned
d
User Interface design mock up’s and specifications should be an
input to the SAP rather than being p
p g produced as a SAP p product
Use Controller Activity Diagram (new notation) to identify and
document the business scenarios as per the identified business use
cases
Object es of the process a d t e o es a d espo s b t es o a
Objectives o t e p ocess and the roles and responsibilities of all
participants should be clearly stated at the start of the process
All decisions, actions and action owners should be documented for
each workshop
Ensure business requirements are documented at the right level of
detail, not necessarily using UML (depends on capability of BA’s)
Use a data mapping approach to ensure all data elements from
user-
user-interface through to stored procedures or SDO’s (Service Data
Objects) can be traced and verified
j )
Ensure vendor engagement model is agreed prior to process - since
this impacts the resources (esp. developers) who will participate in
the process and who may potentially develop the solution
Date: February 07 BEA Pty Ltd - SOA Case Study Page: 18