SOA

SOA, Cloud Computing, and Event and Model Driven Architecture

by

SOA and Cloud Computing, the Predicate to Model and Event Driven ArchitectureIn a recent post (see Functions Required in the Cloud PaaS Layer to Support SOA), I discussed two SOA patterns and two Cloud Computing patterns and showed how they are, in fac…

SOA, Cloud Computing, and Event and Model Driven Architecture

by

SOA and Cloud Computing, the Predicate to Model and Event Driven ArchitectureIn a recent post (see Functions Required in the Cloud PaaS Layer to Support SOA), I discussed two SOA patterns and two Cloud Computing patterns and showed how they are, in fac…

The Service Oriented Enterprise

by

It’s now fourteen years since CBDI was formed. In the early days our mission was, as a think tank, to evangelize new ideas of modularity, separation, contract based and service orientation. We had a vision then; it was the enterprise, every enterpr…

The Service Oriented Enterprise

by

It’s now fourteen years since CBDI was formed. In the early days our mission was, as a think tank, to evangelize new ideas of modularity, separation, contract based and service orientation.

We had a vision then; it was the enterprise, every enterprise, as a set of services deployed in a cloud.

Of course over the years we have become immersed in the details of best practice, education, and assisting larger enterprises to leverage and realize the SOA concepts. But the vision is still there.

It was around 2005 that we first started thinking about capability as a formal concept. The first report on the subject was in June 2006, and at that time the CBDIers started a long running debate (well argument actually) about this concept. There were two primary issues. First, should a capability be standalone or could it be an integral part of a broader application and technology infrastructure. In the end we couldn’t agree and we compromised in identifying capabilities as standalone or not standalone. I will admit I was in the first camp, and remain there today.

The second issue was should organizations be planning for the entire enterprise to be comprised of capabilities. To be honest this issue received less attention and in the end we never published advice on this. Perhaps it was just too early. Also in those early days there was confusion over capabilities. Was a capability part of a business process, or did the capability subsume the business process? Well of course these questions have long been resolved with experience.

But whilst the capability concept is now widely understood, I wonder how many enterprises have actually taken it to the logical conclusion and organized (their SOA and indeed the business) around them? I see many pretty capability maps, but fewer capability services.

The reason I am returning to this subject is because many organizations are now rebooting their SOA initiative and they should be looking at capability services as the foundation of their architecture. Why?

1. Business capabilities represent a common perspective shared by business design and service implementation.

2. Properly structured capabilities are completely independent (see above) and facilitate change with the minimum horizon of impact. They also support practical analysis and classification of services as core or context which facilitates the sourcing decisions.

3. Looking at how the world works today, the primary strategy must be around ecosystem collaboration. Choose what capabilities are core to your enterprise and specialize in them. Organize around them. Conversely identify the context capabilities and figure out what collaborations will be most complementary and go make partnerships, or offshore or outsource or rent from the Cloud.

4. Plan to implement the entire core of the enterprise as a set of strategic capabilities that are smart, autonomic, and talk directly to the real “end user”. Eliminate all other process interventions and optimize the core capabilities using the very latest technology. Architect and engineer the capabilities to be capable of continuous evolution.

5. Stop talking about SOA, start talking about the Service Oriented Enterprise. It’s a business issue.

We have dedicated this October 2011 edition of the CBDI Journal to this topic. We advise that business design should be synonymous with capability design. In my report on Business Design for the Service Oriented Enterprise, I explore a series of patterns for the smart, continuously evolving, virtual enterprise. I discuss the convergence of ecosystem automation and autonomics, architecture for continuously evolving business, together with the merger of consumer and business IT and how these will have a profound impact on conventional business models, which will in turn affect business modeling techniques and enterprise architecture. In addition we have in depth reports on Capability, Planning and Analysis.

CBDI Journal October 2011

Business Design for the Service Oriented Enterprise

Capability Planning and Analysis


Mission Impossible? Or how to achieve the SOA vision.

by

When I am asked about the state of SOA, I sometimes comment that anything involving architectural change is bound to take a little time. But my more considered response would be that whilst the impression of SOA is now widespread, true implementation of the SOA vision, for most enterprises remains a distant vision, if indeed they still remember what that was.

For me the vision was encapsulated in the report by one of our customers on their SOA progress in 2009. They reported their systems were exploding in size and complexity. They had scant standardization, and there was no single truth. If a core process broke they would change it to fit the application, rather than the other way round. This was crazily expensive to maintain. After four years of transformation they report a 20% reduction in IT staff, 1500 systems closed down, the ability to turn services on automatically for customers virtually as they place their orders and a massive reduction in complexity demonstrated by a rental price change that previously required changes to 42 systems – followed by three months of testing, now requires just one platform adjustment that automates the change process. THAT’S STRATGIC!

In contrast I read a Forrester survey[1] from last year that reported while 47.4% of respondents work in organizations where SOA projects are underway, the original reasons for SOA, reuse and cost reduction, have morphed into data integration, legacy integration, flexibility of application development, and department-level application integration. Perhaps this is why we at Everware-CBDI are observing numerous inquiries about “SOA Reboot”, which is variously explained as interest in doing SOA properly, realizing the vision and or delivering real business benefit.

For many enterprises the root cause of this lack of achievement is very straightforward – SOA requires a strategic initiative that looks longer term than most enterprises are able to do. But for most enterprises this is mission impossible, they are bound by short term goals and budgets.

The solution is not rocket science. What’s needed is a governance system that manages a progression from tactical to strategic. Many SOA efforts today are business process project focused, because simply put that’s where the business priority is today. What’s needed is a governance system that ensures project service solutions can be evolved to become enterprise services, where it makes sense. The overhead in making this leap is that a few new policies are needed that spell out better working practices. Consider some candidate policies.

  • All new components and services MUST comply with a defined minimum level of reference architecture.
  • Implications and strategy for future service reuse is a REQUIRED element of all Plan or Feasibility phase end reports.
  • All projects MUST reuse and evolve existing (loose coupled) services and components before acquiring or building new components

There’s more; to make this work needs good governance plus a product (sic) management system in place, because it will get complex. But it works.

I am writing this practice up for the Quarter 4 CBDI Journal. Make sure you are a registered subscriber so you get a copy on publication.

[1] TechTarget/Forrester Research State of SOA Survey for 2010

http://media.techtarget.com/searchSOA/downloads/TTAG-State-of-SOA-2010-execSummary-working-523%5B1%5D.pdf

… so you should do a SOA Certification! But which one? And how?

by
After a near death experience SOA is alive and well. After mixed early learning experiences, most enterprises are seeing SOA in a fresh light. Just the other day one company was discussing with me their “SOA Reboot” project! They are in good company.
I observe widespread activity that is based on doing SOA properly a second time around, including portfolio planning, shared services, good governance and not least education and certification of in-house practitioners and service providers’ personnel.
There are several sources of SOA education and certification including ZapThink, SOA School and Everware-CBDI plus several of the larger vendors. At Everware-CBDI we have approached the certification process as a result of our extensive model based practitioner experience and the creation of a comprehensive methodology and approach documented in the CBDI-SAE Knowledgebase. Our customers who have subscribed to the CBDI Journal over 14 years acknowledge us as an authoritative source of in-depth practice guidance for business driven architecture, specification, design, management and governance.
Our approach has been rather different to the other vendors.
1. We realize that while certification is important, it is critical to minimize the cost and particularly the time involved in obtaining a quality certification.
2. We have prioritized making the entire process online from start to finish.
3. Time and cost optimization is particularly important for service providers who are driven by high utilization targets. Equally end user enterprises and government departments are also under pressure and appreciate sharp focus.
4. We don’t re-label videos of Face to Face classes as eLearning; we create short, narrow focused, fully scripted elearning modules that are purpose designed.
5. We organize the modules into syllabuses for different roles. Of course SOA is about architecture, but we package the learning for architects, designers and project managers to make it as efficient as possible.
6. We believe education and certification is part of continuous learning and skills development. That’s why our certification is backed up with the CBDI-SAE Knowledgebase containing detailed meta models, profiles, process descriptions, patterns, task and technique descriptions, together with deliverable templates and other useful tools, plus a vast inventory of guidance. All cross referenced and consistent with the eLearning. A practitioner’s toolkit!
The table below attempts to compare the options available for education and certification. E&OE.

CBDI ZapThink SOA “Schools” Vendor Training
Online Learning and Certification ☑ ☑ ☒ ☒
Online Price $1200 or $399 per syllabus $1995 ☒ ☒
Integrated Best Practices, Guidance and Resources ☑ ☒ ☒ ☒
Syllabuses for Architecture PLUS other roles ☑ ☒ ☑ ☒
Self Study Resources Bundled ☒ $1596 or 50% discount with F2F course ☒
Certification and Exam Cost Bundled Bundled Bundled $200 – 300
In house Corporate or individual use. Volume discounts ☑ ? ? ?
SCORM compliant for enterprise LMS integration ☑ ☒ ☒ ☒
Vendor Independent ☑ ☑ ☑ ☒
Deployed online by world leading service providers and enterprises ☑ ? ? ?

Try the sample CBDI eLearning and Certification Modules (no charge registration required)