1

Courtesy of TibCo - Owner of site : http://www.gregthearchitect.com

2

3

4

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

Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT SOA Presentation Oct. 2007.

12

SOA Presentation Oct. 2007.

Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT SOA Presentation Oct. 2007.

13

SOA Presentation Oct. 2007.

Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT SOA Presentation Oct. 2007.

14

SOA Presentation Oct. 2007.

Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT SOA Presentation Oct. 2007.

15

SOA Presentation Oct. 2007.

Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT SOA Presentation Oct. 2007.

16

SOA Presentation Oct. 2007.

Slides from Courtesy of: Frank Carvalho, IT Architect, SKAT. From a SKAT SOA Presentation Oct. 2007.

17

SOA Presentation Oct. 2007.

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.

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?zn=bto&cp=1-11-15-25^1059_4000_100__

In order to build your Service Catalog (for your Customers, no matter if internal or external to Service Delivery), you have to start defining internal 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 !

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 !

*) 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

*) 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.

****)

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

You find this presentation on the conference Portal of itSMF.dk for the Autumn 2009 conference.

32

Autumn 2009 conference.