IT Services Stack

[Jack541108]

I started the construction of a comprehensive IT Services Stack. I'll make it available to the public domain. The early setup is available here:

http://soa-eda.blogspot.com/2008/03/it-services-stack-collaboration.html

I would appreciate to get input from professionals in order to mature and extend the model. Perhaps anyone of you CEP forum readers could provide some input on event-related topics and/or give the initiative some attention on your blog or web site.

Thanks,
Jack

[PVincentTIBCO]

Jack - Some initial thoughts:
- (Maybe) This is not a proposed standard, so probably should go into general discussion folder...

- Business level:
-- see Business Motivation Model for other entities here (eg strategies, means, ends); at some level business = governance, policy etc (your right column)
-- Ron Ross - type Business Rules apply here (see BMM, SBVR etc)

- Process level:
-- agree with James T that you need Decisions here (but disagree that these are different from process rules - they are all decisions!)

- Business Apps:
--EDA and SOA are architecture patterns / frameworks (Tech Infrastructure), not business applications
--- compare with BPM: with BPM you set up users, roles, processes at the business level. These are supported by services (orchestrated or event driven)

- App Infrastructue
-- CEP applies here
--- Supports BAM in level above

- Security and Monitoring at each level - this is really a business level issue, supported also by CEP (and others)

[Jack541108]

Thanks for your comment, Paul. It is highly appreciated.

I recognize some ambiguity with regard to "application". In my model a business application might be defined as software algorithms with focus on supporting business processes. I agree with you that SOA and EDA are architecture patterns. But I disagree it is not about business applications. In my opinion - from a real life perspective - these architecture patterns strongly focus on how to apply a software based supporting layer to the business processes. And so being part of the business applications at the same time as being - more idealistic - an approach to shape the business processes.

The same applies to BPM as a means of how shaping business processes (horizontally) AND how to link the business processes to the software layer (vertically). In real life BPM is synonymous with tooling to shape business processes and which spawns BPEL (software algoritm) to execute the processes in an IT-environment and thus being some kind of business application itself.

And also CEP - closely related to BAM - has everything to do with software based algorithms to support business processes by correlation (software based representations of) business events. And thus belonging to the business application layer IMHO.

In short: I tend to view the whole picture, business and IT. I consider the business application layer as the IT counterpart of the business process layer.

-Jack

[PVincentTIBCO]

I recognize some ambiguity with regard to "application". In my model a business application might be defined as software algorithms with focus on supporting business processes. I agree with you that SOA and EDA are architecture patterns. But I disagree it is not about business applications. In my opinion - from a real life perspective - these architecture patterns strongly focus on how to apply a software based supporting layer to the business processes. And so being part of the business applications at the same time as being - more idealistic - an approach to shape the business processes.

Hi Jack: but surely pretty much *all* IT systems are in some way supporting business applications? For example, how is "MDM" less of a Business Application than "SOA"? Surely MDM is pretty much an application implementing a business service...

The same applies to BPM as a means of how shaping business processes (horizontally) AND how to link the business processes to the software layer (vertically). In real life BPM is synonymous with tooling to shape business processes and which spawns BPEL (software algoritm) to execute the processes in an IT-environment and thus being some kind of business application itself.

Well, for sure BPM *can* result in BPEL (presumably a type of Process Server). [Side note: other tools like service orchestration tools can map to BPEL (e.g. TIBCO BusinessWorks has a BPEL2 engine option)]. I'm guessing "Rule Engine" is just a special "process server" in your diagram, although a CEP-based rule engine might be more better classified under the Event Processor box.

And also CEP - closely related to BAM - has everything to do with software based algorithms to support business processes by correlation (software based representations of) business events. And thus belonging to the business application layer IMHO.

I think most in the CEP community would agree that CEP technologies overlap with / are used by BAM (e.g. TIBCO ServicePerformanceManager is built using TIBCO BusinessEvents (CEP)). And involves software algorithms, and supports the business. Usually it ties to an EDA. But you have Event Processing in App Infrastructure, and EDA above it, which does not seem right. And BAM is replicated in meaning by the "Monitoring" box...

In short: I tend to view the whole picture, business and IT. I consider the business application layer as the IT counterpart of the business process layer.

Yes, I probably misconstrue the meaning of the relative positions of your components: so you have SOA above DBMS services, whereas I would view SOA as a concept that supports such persistence services (ie would fit underneath). It depends what verb relates the layers: Activities "automated in" SOA "uses" ESB "uses" Network Svcs ?
Might also be worth looking at relevant Business Architecture structures, too.
Cheers

[Jack541108]

Hi Paul,

You got interesting insights. I think we could talk for hours.

Perhaps I should take some time to explain the essence of my model (preferably with a glass of beer in a pub).

You are right in viewing the layers top-down in terms of "uses". Bottom-up you might say "delivers services to", so that makes the model sort of IT services stack.

E.g. your interpretation "you have Event Processing in App Infrastructure" is not quite how it's meant. I have "Event ProcessOR" in App Infrastructure as the processor is an infrastructural engine that runs input (software based algorithms) form the application layer. Constructing these input files to be processed by the Event Processor is just programming which belongs to the application layer. Just like writing Java code belongs to the application layer and is run by a J2EE application server at the App Infra layer.

The model is meant to decompose and order entities in a stack-like layering where the layers constrain the communication between the entities. The lower the layer, to more generic the components (entities) compared to the business levels (greater "distance"). The models helps me through every IT-architectural discussion but I guess things are less obvious to others than I expected. I should express myself better I suppose...

Nevertheless, your comments all make sense to me.

-Jack

[PVincentTIBCO]

Hi Jack: encompassing stacks are a good idea though, so although some of us may disagree with how you've laid out your stack, I wouldn't want to discourage its continued development. At a similar level we at TIBCO are interested in model-driven engineering and the use of standards like BPDM to encompass multiple models of process definition (CEP to workflow). At a much coarser level we, for example, describe business optimization (CEP, BI, advanced UIs) driving processes (BPM / workflow) delivered thru services (SOA / ESB / service virtualization / SLA mgmt).
Cheers