The hyped Service Oriented Architecture (SOA) around 2005-2010, did pose some new challenges to IT.
Is SOA matured in terms of easily getting over the Transition from Project to Operations ?
What is happening 'behind the scenes' of a SOA solution, during Design and Engineering ?
- Challenges and Problem areas you should watch for
- And perhaps a few hints to avoid pitfalls
6. My emphasizing here, is just a personal hickup, to those cutting-edge
guys now talking beyond SOA, around hypes such as:guys now talking beyond SOA, around hypes such as:
•GRID, which is indeed an special breed of technology
•SaaS, Software as a Service, could make sense if we can avoid Service
Warranties covering the Internet !
•Cloud Computing, which is somewhat foggy still
7.
8.
9.
10.
11.
12. Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT
SOA Presentation Oct. 2007.
12
SOA Presentation Oct. 2007.
13. Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT
SOA Presentation Oct. 2007.
13
SOA Presentation Oct. 2007.
14. Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT
SOA Presentation Oct. 2007.
14
SOA Presentation Oct. 2007.
15. Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT
SOA Presentation Oct. 2007.
15
SOA Presentation Oct. 2007.
16. Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT
SOA Presentation Oct. 2007.
16
SOA Presentation Oct. 2007.
17. Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT
SOA Presentation Oct. 2007.
17
SOA Presentation Oct. 2007.
18.
19.
20.
21.
22.
23. CSC in this case agreed to support the use of:
-Systinet (now HP) MetaRepository (MR for short)
-Extended UDDI (as hosted by the AquaLogic Service Bus – ALSB (was
BEA and now Oracle) and governed by AmberPoint. We call this the
Service Registry (SR for short)
-To have the CMDB governed and in control of BMC Remedy 7 (The
CMDB component of BMC Remedy is called BMC Atrium)
But, since CSC operates other Clients too, in a leveraged Support Model
(support teams covering more than one Client), the above Toolset, has to
’fit’ within the Processes, Procedures/Work Instructions already out there !
The ’constraint’ of having the SR part of the Run-Time environment, forces
you to create automatic datafeeds among your Repositories, taking into
consideration where your data ownership resides ! Otherwise you end up
with a mess of updates out of control. One of the mechanisms to make
use of, is the Release Build process, which clearly creates a milestone in
a higher sense. Use these kind of ’Use-Cases’ to secure your data-feeds.
24.
25. The following artefacts has been added to the standard UDDI data model:
•an extra tModel called Class
•a link to the SLO documents in MR
•a Contract associated with the BusinessService
See more here around the UDDI:
http://www.uddi.org
And HPs rather new Universal CMDB offering:
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?z
n=bto&cp=1-11-15-25^1059_4000_100__
26. In order to build your Service Catalog (for your Customers, no matter if
internal or external to Service Delivery), you have to start defininginternal or external to Service Delivery), you have to start defining
Core Services first ie. you would need to build your Service Catalogue
from bottom-up ! You can’t start building a house beginning with the
roof !
Often, your Core Services would be very close to what you get from your
Infrastructure Management organization, so my advice to you is:
1. Include those guys to be part of your Core Service Package
definitions.
2. The task is to define:
a) What are your Service Utilities?
b) What sort of Service Warranties can you apply to those
Service Utilities ?
3. The combinations, will then become your Core Service
Packages !
4. Document these and their constraints and pre-requisites too
5. Done !
27.
28. Since the CSC Contract was ‘baselined’ to a near ITIL V2 Service
implementation we had to work with this scope in mind.implementation we had to work with this scope in mind.
But now with ITIL V3, everything seems much clearer now !
For example a ‘Service Design Package’ would perhaps helped for the
last Transition into Operational state.
But be careful not just jump to what seems to an easy way out on the
short term solution [by copying Repository details], it may very well be
expensive on the long term !
29. *) Knowlegde is still - in the 21 century - best to be captured in writing !
Don’t rely on Knowledge Tools alone to save your day.
29
Don’t rely on Knowledge Tools alone to save your day.
**) Courtesy of an ex-CSC Manager: Benny Hansen
30. *) Yes, you heard me right ! You have to know how hardware works with Resilience (for Business
Continuity) in mind. Like:
30
Continuity) in mind. Like:
•How does SAN work with mirroring ?
•How does your DB work when sitting on top of SAN with Mirroring ?
•How do my proxy servers work, with failover of sessions ?
•…
**) The Metamodel accompanying the IT Service Management tool of yours (don’t swear using the
CMDB word !), are likely not aware of SOA, and the Metamodel accompanying your Development
toolset, does not know much about Service Management !
As mentioned earlier on, define Use Cases for your development methodology as you would do
with your business ! In this way, you get a common language.
I find, that its important to share common denominators, most importantly the artifact ‘IT Solution’ is
inadequate for Operational purposes, so I suggest the artifact Environment much better represent
both. We all know what a Production environment is, more than System xxx, which may even be
deployed in many Systems…
A System says a lot more to a Developer than to Operations, and Environment says a lot more to
an Operator or Service Desk (and others) than to a Developer. So who’s right ?
Do you get my point …?
***) I mean, what I say !
Your ‘Application Servers’ (ie. SOA transactions, basically) to be logically separated from
Hardware, yet the Developer wants to deploy against this, at some future point… So you need
Naming Standard for:
•Application Services, preferably grouped as they would be deployed together (ie. ‘the Application’)
•Environments, already covered in another slide.
•Your LAN designs, you have more than one Environment, they need to be separated, so the
network traffic don’t get mixed. Usually covering VLAN’s and IP Address scheme’s, NAT principles,
FW rulesets (by ‘Application Service’)
•OS Hostnames, to become part of your Environments. Don’t name servers after ‘Applications
Services’, one cannot determine where an run-time Application will end deployed, at System
Design time.
•Physical Server hostnames, to become hosts of Virtual Server guests. Don’t name Virtual OS’s
after which Phsical server they reside, you may want to utilize ‘dynamic resource provisioning’ (ie.
vMotion in VMWare) later !
•Middleware standards too, like:
•Database Servers, with Databases and TableSpaces too
•Domain Names (for communication over the ‘Service Bus’)
•User naming standard, for Production environments, and even Test and Stress Test ditto.
****)
31. My guess is that the road of SOA leads - via the Semantic Web & RDF –
into a future global set of Common Definitions (See URLs below). Today,into a future global set of Common Definitions (See URLs below). Today,
these are written in English (for the moment), but my vision tells me we
will see some sort common language... by which we can exchange
business process code, design stuff together, agree on common business
artefacts and verbs etc.
Ref. http://www.w3.org/RDF (depracated) and
http://www.w3.org/2001/sw
And Ontologies with Web Ontology Language (OWL):
http://www.daml.org/ontologies and
http://www.w3.org/2007/OWL/wiki/OWL_Working_Group
I don’t know were the road ends, maybe we end up speaking Lojban
altogether, whenever we do business !
[Ref: http://www.lojban.org/tiki/Lojban] (Lojban is a Constructed
Language, like Klingon also is a Constructed language, but perhaps
not as logical – Sorry you Klingon’s)
Anyway, I can’t imagine we can speak BPEL sometime soon…
Ref:http://docs.oasis-open.org/wsbpel/2.0/Primer
32. You find this presentation on the conference Portal of itSMF.dk for the
Autumn 2009 conference.
32
Autumn 2009 conference.