The cost of Medicaid and Medicare has been written about often as government budgets are re-evaluated and the new administration takes root.  With econonmic times being what they are the number of beneficiaries are increasing in an already overburdened system of service to US state and local communities.

In response to concerns over rising costs, complex processes and fragile systems the Federal Centers for Medicare and Medicaid Services (CMS) developed the MITA Framework.  MITA stands for Medicaid Information Technology Architecture.  It is an integrated business, data, application and technology architecture built on SOA principles and best practices.  MITA is a strategy and a blueprint for establishing integrated business and IT transformations in State medicaid programs to tackle the issue of rising costs, complex business processes and fragile systems.  A key challenge when implementing any kind of enterprise transformation and associated SOA project is how to crawl, walk and the run in the rollout of the implementation.  The MITA framework proposes a multi-stage maturity model and many states are assessing how to progress through the stages of maturity.

To help states progress from where they are to the necessary and desired states proposed by MITA, Intel, Oracle and Initiate have come together and assembled a webinar series on approaches to go from MITA theory and recommendations to specific implementations.  This webinar series covers the essential elements of MITA relevant technology stack and how to apply common service oriented best practices with the right software foundation to achieve breakthroughs in key business processes like Fraud Prevention and Chronic Disease management.  The webinars discuss in detail the business drivers, technical architectures, and deployment patterns on how to evolve State Medicaid and Medicare systems.

I hope you get a chance to dig in to the webinars and see how SOA best practices and the right technology mix can make a big difference in US healthcare.  You can register for the entire series on demand here.

Until next time,

Joe

The topic was about the need to standardize, and the benefits of standardizing, software services.  There are many IT standards in healthcare and other industries around document structures, data payloads and information sematics.  Yet, there has been marginal progress on standardizing the functional behaviors or architectures which are needed to create, manage and manipulate that data.

What I think is unique and interesting about what Ken has started is a systematic joint collaboration across healthcare standard organizations.  A collaboration which can result in standards and best practices which cover data structures, information semantics, essential software service behaviors, and associated proven architectures. 

I also think the timing is right.  With the passage of the recent U.S. stimulus bill, there will be the funding, the attention, and the priority given to realizing an approach like this into broad adoption.  I believe this since a comprehensive set of standards beyond data representations will be necessary to achieve the U.S. President's goal of an interoperable, electronic healthcare system at a price that makes sense. 

Until next time,

Joe

We have assembled a panel of Gartner & Burton Group analysts, customers, and events to showcase how service orientation can be a practical transformation agent for key business and IT initiatives.

We call it: "Practical Approaches to Service Delivery", which will be delivered as a webinar series.

Key topic areas include practical definition and use of:

• Federated Governance
• Web Service Security Gateways
• Software Appliance Intermediaries
• Service Router Architectures
• Accelerate Existing XML Integrations

The list of topics and dates can be found here:

• Feb 11:  A Software Alternative to Expensive Security Gateways - How Multi-Core Optimization Delivers a New Breed of Service Intermediary
• Feb 19: Benefits of a Service Router Architecture - Intel IT Reveals a Lightweight Approach to Federated SOA
• Mar 5: Delivering Federated Service Governance at Scale with Maximum ROI - Practical Enabling Technologies
• Apr 14:  Bringing Departmental SaaS Usage Under IT Governance – An Enterprise IT Perspective
  Addressing Enterprise Governance, Security, and Reliability Concerns

The details regarding the session times, contents and speakers can be found at the registration link below.  Also, the material is available for free on-demand reply after the scheduled event so you can access this material at any time. 

To get access to the webinars please provide your contact information at the following registration link.

I look forward to hearing from you at the webinars.

Joe

The discussions take many forms such as:  "What is governance?", "How do I apply it to my service architecture"?, "What vendors are relevant?", "What standards are relevant?", "What features and capabilites matter most in practical deployments?"

I think this is an important topic given the state of service architectures and associated deployments.  Most organizations have many services in their environment and/or product architectures.  The number of applications and associated infrastructure which deploy software services as functional building blocks and / or APIs is increasing all the time.  Also, with the rise of cloud computing and SaaS, the vision of services being sourced from anywhere is an established practical reality.

So, when I think of governing services I am considering three main questions:

1. What are the policies that I need to define and enforce?
2. What is the means by which I will record and propogate those policies?
3. How will I measure, monitor and address compliance as well as exceptions to policies?

Each one of these questions are big.  There are many operational, architectural and implementation considerations associated with each.  As you are likely aware entire product categories such as web service security appliances, web service management apps, and SOA registry/repositories have risen up as a means to provide some answer to each of these three questions.

In my opinion, there are rarely simple answers to complex questions and in this case I believe that a proper answer to these three questions is not a single product selection.   Effective service governance is an design pattern which is applied to address these questions for a particular enterprise from the policy design through policy execution.

Over the next several posts and webinars, we will be sharing a governance architecture derived from the service router design pattern.  Using this design pattern allows an organization to cover their full scope services, leverage established investments in repositories and service management platforms, and execute a wide array of policies from a shared, cost-effective infrastructure.

The next post will get in the next level details on applying the service router design pattern to service governance and announce the webinar series we have lined up on this important topic.

Until next time,

Joe

Feature Highlights:

• Application Runner – Allows developers to test and run workflows from the Intel® Services Designer environment.  Speeds up and simplifies development and test cycles.  
• Programmatic Management – JMX API support allows custom management and monitoring tools to be integrated with Expressway beyond our web interface application
• Attachment Optimizations – Automatic MTOM/XOP support allows for on-the-fly attachment compression for SOAP v1.2
• Temporal Consistency- Support for in-order (FIFO) delivery assurances on inbound messages
• Designer Improvements – New wizards and action builders to simplify tasks that use LDAP, SQL, XSL and schema validation
• Healthcare Standards – Prebuilt workflows for IHE XDS.b profiles

The release scheduled for the end of Q1'09 will include Microsoft Windows operating system support and new additions to our suite of UI wizards, action builders and prebuilt workflows for healthcare payer, security gateway, and service governance usage models.

Until next time,

Joe

Recently I have been forwarded or have come upon a number of articles, webinars, research reports, and blogs with a common theme: SOA has failed.  SOA doesn't work.  SOA is dead.  Maybe it is just me being more sensitive due to my annual ritual of re-evaluation, or maybe there is a real trend underway here.

The term SOA has been around for about a decade.  It has been over-hyped, over used and certaintly there are a number of failed SOA implementations.  Personally, I also think the term has gone sour like that old egg nog in my fridge.  However, tired terminology does not equal a bad architecture.

The software engineering and IT practice paradigms that SOA represents are more relevant than ever.  In tight economic climates like we are facing now, the value pillars of a service architecture (asset reuse and agility) are more important than they have ever been.  Those organizations who can effectively re-purpose their existing IT assets to rapidly align to new business challenges have a very important advantage.  As well as those who can seamlessly outsource parts of their technology and business process architecture as needed.

The rise of SaaS, Cloud Computing, Mashups, B2B Integration, Service Governance, etc, etc, are all founded on the notion of distributed, widely interoperable software services.  Their adoption is rising steadily.  It is very rare to see an architecture for a new application or infrastructure project which does not incorporate software services as functional building blocks and/or APIs.  So, although the term SOA might be on its very last legs I would argue that the use of its principles and design paradigms are more prevelant than ever.  

As I wrote about several times last year, it is hard to manifest a Service Oriented Architecture.  It takes investment, process and engineering discipline which some organizations cannot readily achieve.  SOA is also not the answer for every business problem.  Picking the right problems, putting the right focus on the necessary discipline, and nailing the execution requires help.  Building the right relationships with analysts, vendors and integrators is a key ingredient for success.

The Burton Group is holding a telebriefing on this topic on 02-03 and 02-04.  The title is "SOA is Dead: Long Live Services".  I plan on attending.  If you do, I am interested to hear what you think.

Should we still be talking about SOA in 2009?  I will ... are you? 

Thanks for getting this far.

Joe

The webinar is scheduled for:

Broadcast date: Tuesday, December 16th, 2008
Broadcast Time: 1 PM ET / 10 AM PT / 18 GMT

The registration page is available here at this link.

I look forward to hearing from you at the webinar.  However, if you miss the live event you can access the webinar replay on demand through the registration page link listed above.

Joe

The webinar is available on-demand for those who missed the live event. Just go to the Dr Dobbs registration page, fill out the contact form and then you can access the webinar anytime.

I look forward to hearing your thoughts on the Enterprise Service Router architecture and how it could apply to your enterprise architectue initiatives.

Joe

The full listing is available at the News & Events section of the Intel SOA Expressway web site.

Some notable events:

• On November 13th I will be participating in a Dr Dobbs webinar with SOA industry expert [http://www.linthicumgroup.com/BlogPodcast.html"] David Linthicum at 11 am PST / 2 pm EST.  Event details and registration can be found here.
• On November 19th, Josh Painter will be giving a SOA trends presentation and webinar at the SOAWorld 2008 conference in San Jose.  The session details can be found here and it will be made available as a webinar soon after the conference through the SOA Expressway News & Events page on intel.com. 

We hope to hear from you at one of these upcoming events.

Joe

A recent report by Forrester Research "Building Interoperability And Federation Into Your SOA Platform Strategy" describes this trend in some detail and in particular the importance of "... architects to segment their SOA platform strategy and build in an extra level of interoperability and federation between different SOA domains...".  Key to this advice is making architecture and technology decisions which are purpose fit and "right sized" to the key business problems of connecting SOA across the enterprise and not to over extend, unecessarily reuse or let "accidents of history" extend individual domain solutions beyond their useful role.

In November, we will be sharing more specifics about these industry trends and evolving architectures through a series of webinars and industry events.  As part of the series, we will describe how right-sized SOA architectures and technology such as  Intel SOA Expressway which are purposed built for connecting SOA domains into an enterprise whole optimize integration, performance, security and managbility of key enterprise services and process workflows.

More details on these events will come in the next few posts.

Thanks for getting this far...

Joe

First, SOA is a design pattern.  It is an approach to creating IT solutions.  SOA is something you do, not something you buy.  So, there is always some manner of integration, development and "best-of-breed" engineering in any SOA implementation (usually at a minimum in semantic data definitions).

Given this, the key question then becomes how many SOA capabilities are sourced from how many vendors...

Experience to date has shown that integrated SOA stacks are most valuable in business domains where the entire domain's major business solutions are implemented from a common vendor (like SAP or Oracle for example).  The benefit of integration across the SOA functional layers as well as application logic and data provide a material benefit in the speed in deployment.  However, most organizations don't run their entire business on a single vendor.  Different corporate functional groups (like HR, Supply Chain, and Sales) or different business divisions or geographies have different needs for function, cost, etc. so it is very common to find different vendors serving those different needs.  This very common situation results in the development of a Federated SOA deployment.

This common fact means that neither "all-in-one" nor "best-of-breed" is a single solution for most organizations deploying SOA.  Rather some aspects of the business will benefit from "all-in-one" when there is a good match between business process functional and data needs to a stack vendor's business and SOA suite, and that a "best-of-breed" model will almost always be required to connect business domains into an enterprise whole.

Therefore in the development of our SOA platform, Intel SOA Expressway we chose a different model.  Rather than being a "all-in-one" or "best-of-breed" we chose a different path we call "right-sized".  In the "right-sized" model the necessary functions to achieve a specific set of SOA-enabling objectives are bundled into one complete package.  No seperate piece parts, or up-sell modular add-ons.

With Intel SOA Expressway our objective was to optimize the scalability, security and managability of a SOA deployment.  To achieve that objective we bundled network protocol handling, data translation, service virtualization, process orchestration, security mediation, and appliance level manageability features into one highly optimized platform.  To leverage those features in a Federated SOA architecture, we enable standards-based interfaces and tooling to governance repositories, message-oriented middleware, databases, portals, shared security infrastructure like LDAP directories, and vertical market specific service implementations.  The net effect is that through these standards-based interfaces and a validated partner ecosystem a "right-sized" architecture provides the purpose-built fit for a Federated SOA architecture and many of the time-to-value benefits of the "all-in-one" stack.

During the next few posts, I will share more details on how the "right-sized" SOA platform architecture works and how the Intel SOA Expressway validated partner ecosystem is evolving.

I look forward to hearing your thoughts on the "all-in-one" stack vs. "best-of-breed" debate and how you have applied that thinking to your SOA deployments.

Thanks for getting this far...

Joe

Selecting a vendor who delivers a highly optimized application platform for multi-core hardware is the most direct path to realizing that value proposition. However, not all business problems are solved by packaged platforms; often a level of company specific development is required to support the need for IT solutions. In those cases, it can be more challenging to realize the performance and scalability advantages of multi-core. To ease this challenge, there are a number of resources available to developers in the form of training, libraries and development kit tooling at the Intel® Multi-Core Community.

One question that I often get asked is: Are there higher order development tools above libraries (like the TBB) or tuning tools (like VTUNE) that can ease the implementation of company specific application functions or extensions that are multi-core optimized?

As it turns out this is another good application of a SOA “Soft” Appliance, like Intel SOA Expressway. Using tooling like this allows the developer to visually define process orchestrations, setup discrete, modular functionality as reusable services, and implement solutions to specific company problems like data conversions and security enforcement policies without writing code. Yet at runtime, these functions run in a finely tuned and highly optimized manner for multi-core hardware. It is the simplest way to get the full performance and scalability benefits of multi-core processing when developing custom solutions to a specific enterprise application need.

Thanks for getting this far.

Joe

I also participated in the conference to deliver my point of view on the theme.  Acknowledging that the non-technology components are critical areas of success (see my thoughts on this in the Intel Press Book SOA Demystified in Chapter 2), making prudent technology decisions is also important or what you end up doing is putting a good plan and a good team into a number of comprimising positions.

As discussed in an earlier blog on federated SOA, a practical reality for most organizations scaling their adoption of SOA beyond a single pilot, department or use is that one single unifed implementation is rarely ever a practical possibility.  So often the architecture and technology discussion becomes, which of the currently deployed SOA stacks should be extended to cover the entire enterprise.  My point of view and one shared by other speakers at the conference is that this is really often a comprimise discussion, that is "...which one are we willing to live with more than the others...", where the discussion should be is what are the key capabilities needed to support the top-level federated architecture and what incremental investments are necessary to get to that architecture.  More often than not the practical matter is that security, cost of performance, scalability and managability are key vectors for this top level architecture which may not have been the most important components of the service enabling and compositing layer of a specific application stack that is widely used in one corporate department or region.

Also, as I shared in an earlier post scaling the implementation of SOA when applying open, loosely coupled technology standards like XML, HTTP and SOAP can be a challenging proposition when volume and latency requirements are steep.  Loosely coupled, open standards provide substantial reuse and agility benefits, but often a comprimise discussion ends up happening as to how this aspect needs to be de-featured to support performance and latency requirements.

With a SOA "soft" appliance platform like Intel SOA Expressway, there is no need to comprimise.  It effectively extends across individual SOA deployments by site, department or region creating a unified whole with a scalable and high performance messaging, data integration and workflow compositing / orchestration stack so there does not have to be a trade-off as to whether the open, loosely coupled standards will scale.

With the right technology foundation realizing the value of SOA at an enterprise level without comprimise is readily achievable.

Thanks for getting this far.  I look forward to hearing your thoughts on how you are approaching the question of how to scale your SOA deployments and what trade-offs you are making in those strategies.

Joe

We have recently completed a new benchmark with a financial services ISV, m35 in London demonstrating the performance of Intel SOA Expressway.  In this demonstration, the combined Intel and m35 solution processed 1.6 million PV risk calculations per second, or 5 billion in less than one hour.

This combination of m35 and Intel clearly demonstrates that complex financial processes and calculations, which take many data feeds from diverse sources can be aggregated and executed in near real time workflows with standard software tools, data protocols and multi-core server infrastructure.

Thanks for getting this far.  I look forward from hearing from you about your complex and high-performance use cases in financial services.

Joe

We have a build of the SOA "soft appliance" called Intel SOA Expressway for Healthcare which solves many challenging data interoperability problems for hosptials, insurance companies, government organizations, and individual clinical practices.  Josh Painter has started a blog on the use of SOA technology in healthcare and life sciences where you can get more details.

Over the next several posts, I will share my thoughts on how the capabilities of a SOA "soft appliance" in performance, security and mangability optimization solves tough problems in specific vertical markets.

Joe