Business Making Progress

Multi-tenant Distributed Process Environment (Part 2 of 2)

Last week at Chennai, Nasscom EmergeOut conclave recognized the prominence SaaS & Cloud hold in IT psyche today, and they had Innovation in the SaaS/Cloud space as its primary theme. I chaired a session called 'Software Procurement Model Trends'. It was interesting to note the amount of serious adoption in the whole gamut of companies from very small startups thru SMEs to large corporations like Diamler. And while today it is more about Software as a Service (SaaS), companies are now beginning to seriously look at Platform as as Service (PaaS) as well.

I also shared views on  SOA & BPM in the Cloud at the Great Indian Developer Summit in Bangalore last month and geared my thoughts on multi-tenant business processes. Like I had noted in my earlier post, as business processes get more integrated into the enterprise IT infrastructure landscape, new solution architectures are possible. We’ll begin to see whole cloud and distributed application models being encapsulated into single-solutions with embedded business processes. We’ll see these same solutions being deployed on the cloud, and even further being deployed in a dynamically scalable multi-tenant model.

This is, in my view, the more advanced of the three possible models for SOA/BPM in the cloud:

• Using Business Process Management (BPM) for integrating applications in the cloud
• Above BPM itself running in the cloud
• BPM embedded inside solutions running in the cloud (single-solution view)

BPM in a SaaS model, wherein one can model and execute their business processes over the web, is not exactly new. Gartner reviewed the web based BPM modeling and deployment possibilities in 2008, and cited the three possible deployment models:  For each application instance it may have its own BPMS and repository on a shared server, or a shared  repository, or the extreme form of shared BPMS+repository an a shared server. The whole web based BPM modeling and deployment fad has come and gone. This is partly due to limitations on the kind of use cases that fit in into BPM on the web, with solutions and services they access possibly being within the enterprise. And accessing services inside the enterprise firewall from outside is not the easiest of configurations to open up for secure access. So, model and execute on the web in a SaaS model is probably still time away from mainstream adoption. Until enterprise IT landscapes mature some more; with more widely distributed solutions over the web- possibly accelerated by rapid acceleration of SaaS model business solutions and also the accelerated adoption of public clouds within enterprises.

Now, one possibility not explored much is BPM and SOA becoming an integral part of a single solution. Though SOA is an integration paradigm and BPM is a model-driven business process layer targeting integration solutions & human workflow processes, both do offer a very elegant model for today’s modern applications. The granular coarse-grained services professed by SOA is a very good way of partitioning and abstracting sub-systems in any application. What’s more, BPM is a good mechanism to model all first level business processes and flows in any application. This is the single solution view of SOA/BPM.

However, once we switch to a single-solution view, with SOA/BPM being used in the solution as a first order design paradigm (and not just to integrate external applications or services), SOA/BPM can exist in two forms. 1) A simple solution model with an embedded BPM layer that helps organize the solutions functional sub-components better thru coarse-grained services, and all first level of solution capabilities modeled and realized as BPM processes. 2) A solution model that is actually distributed, but still in a single-solution context enabling and providing functionality for a single business solution. Extending this further, you could look at this single-solution environment as one that actually has distributed functionality (a la normal SOA - even as all the web services are essentially modular functionality that aggregate to form the whole application). These applications will use distributed sub-components in a SOA services abstraction and have business processes that provide a higher level of functionality in the application that access these components. Similar to the single solution view described above, but now these sub-components and business processes also are distributed across servers.

It is in this single-solution SOA context that SaaS and multi-tenancy become relevant. Using this model, an ISV could build an application on a platform that leverages the modularity offered by SOA abstractions and the easily customizable first level business process flows enabled by BPM. And, they can make this application available in a SaaS model. If there were to be a BPM+SOA based application platform made available by any of the BPM/middleware vendors, then it is only natural to expect this to also support declarative multi-tenancy.

Multi-tenancy enabled BPM/SOA-platform? Does it sound far-fetched? Not really… Last my month my class (Internals of Middleware Systems course at IIIT-H) built a multi-tenant SOA platform as the course project. They demo’d the solution at the end of the course. It had full working declarative multi-tenancy built into the SOA platform they built, and it included a business process (orchestration) engine based on Camel and a web services platform, registry and repository, and declarative multi-tenancy. (Phew! J ). I was pleasantly surprised. They actually got the whole solution working (albeit in a basic POC mode). So technically, a PaaS for Multi-tenant BPM/SOA based applications is definitely feasible. Sometime, hopefully soon, there could be commercial offerings in the market.  

Multi-tenant Distributed Process Environment

As part of the Internals of a Middleware Systems course (one of the two courses I teach at IIIT-Hyderabad), I wanted to dabble in multi-tenant service oriented architecture (SOA) as a course project. About two months back when I first thought of this as the project, I assumed it was going to be an academic exercise where the class would build some interesting multi-tenant SOA platform (building on Camel, CXF on JMS, with a home-grown approach to partitioning the tenant domains for same set of services & processes (camel routes) available in the environment). But as I started getting more into it, I began to realize that there is probably more to it than an academic angle!

We actually started looking at business processes as being a more integral part of an application infrastructure, and not necessarily just part of the integration layer. Our thought process even brought us above and beyond our recently introduced OpenEdge BPM solution that enables our Application Partners to have key parts of their business logic defined as BPM processes, thereby allowing easier customizations for unique business flows and requirements. (Many years back had proposed embedded buziness preocesses (in Java applications) as a theoretical possibility in application architectures. At that time didnt realise there will actually be a simple platforms that brings both BPM & application logic together as well as our OE-BPM now does). With BPM and application logic now part of an integrated platform, it is only question of time before this architecture extends to a more distributed deployments with application logic composed as distributed services that is then orchestrated in the BPM layer to enable first level business capabilities and flows. Thus bringing in SOA also into the mix. And the moment this solution goes on the cloud in a SaaS model, the whole platform- Application logic, SOA & BPM- will now need to be multi-tenant capable.

Most of multi-tenant SOA seemed common sense.Still, when I was trying to find some academic basis, I came across this comprehensive overview in an IEEE article, Multi-tenant SOA Middleware for Cloud Computing. This article summarizes the various aspects of multi-tenancies - from the well known models for database centric solutions to enabling multi-tenancies (one DB per tenant, one schema per tenant or the more advanced tenants across multiple schema's (each shared)), to the more complex problem of actual application multi-tenancy. The application multi-tenancy also had a sound approach presented in this paper - Architecture Strategies for Catching the Long Tail - where they present a few levels, from the basic custom instance per tenant, to the next level where it is still one instance per tenant but the application is architected for easy configurabation. This paper further presents the next level where there is a shared instance that can service multiple tenants, to the most advanced level that it is a shared instance across tenants that can also be clustered & made highly-available. All great stuff. But what does this mean for SOA and BPM environments?

The more fundamental question that begs to be answered is what is the play for SOA in the cloud? Is there a SaaS play at all involving SOA? In the past few years that I've been dabbling in cloud  computing and talking about cloud environments at seminars here in India,  I never really thought SOA had a major angle. But surely in today's enterprise IT landscape, any enterprise integration solution will need to also access solutions in the cloud either by running a SaaS platform, custom built on a PaaS platform, or in a cloud-based virtual infrastructure platform. As SOA adoption matures, the other aspect that is rapidly emerging is a new class of business applications that use business process management (BPM) and service abstractions as a more integral part of solutions. All the simplicity, rapid development, composability and maintainability value that SOA offered for enterprise integration (in terms of atomic coarse grained business functions and processes that are composed off of these services, and that are easy to define and modify), now makes sense even for individual applications. Who would say NO to applications that are easy to build and maintain?

Given this, the use cases emerging for BPM solutions are now very different. And once BPM and SOA get into the application architecture, the need for (and value from) the cloud and multi-tenancy is immediate. We've seen the SaaS model get serious traction from ISV's because it delivers flexibility as well as a low-cost & ease of ownership. Once we go the full hog, then why just business processes? The applications can also have first level business services (aka SOA services) that can be composed into next level business processes and business workflows. A full-fledged SOA platform now forming the basis for applications.

So, in order to multi-tenant enable these BPM + SOA solutions, what are the challenges? ...Stay tuned.

Busy week in India (Product Conclave and SOA Summit)

Over the past few years there has been a significant rise in new tech start-ups in India.This is most evident at the National Software Products Conclave organised by Nasscom (national industry body). Till a few years back this was essentially for, by and of global multi-national product majors and few leading Indian product companies. In past two years, however, this has transformed to now an event completely targeting tech start-ups. A very demand driven shift! This years edition is due next week and theme is Lean Startups in the Cloud.

I am happy to be part of this event. I am part of the core organizing team, and am moderating a panel discussion on the opportunity being opened by UID (a majorly funded federal program to issue citizen IDs - a la Social Security Number in many countries ).Topic being - Ride the New Mobile Solutions Wave Triggered by UID. The UID organization, headed by Infosys Co-founder, is looking at much beyond just the ID. Implicit in the envisioned architecture is the mechanism to authenticate ID verification with bio-metrics also in place. And this is being made available to all solution providers and SIs to build custom solutions in segments ranging from Supply Chain, Logistics and beyond to bottom of pyramid solutions. This is a serious opportunity for a completely new class of solutions. And lot of interest from the government to promote the platform and encourage new solutions. This is by and large a distributed solution with potentially large number of users/endpoints involved. Our Responsive Process Management may also have a play in this. I will be moderating the discussion to identify such solution possibilities. At an event with over 500 start-ups, and leaders from few hundred established product companies & SIs, present!

While on Responsive Process Management, one more interesting opening is that at a Business Technology Summit due also next week, have been invited to talk on  'Beyond BPM'. Here again, our vision for beyond BPM is Responsive Process Management, Where business process management in an organization is extended to the processes that are not yet automated thru SOA Orchestration or BPM. Without any re-engineeirng, to extend the visibility and control that BPM enables to other non automated processes in the enterprise. My talk will discuss extending BPM models to Responsive Process Management as a emerging solution space, and what it can mean for businesses. How the RPM as a solution approach helps with the sense and respond decision control based on modeling and tracking business flows without changing/modifying the code of any of the existing applications that participate in  the business flows.

Looking forward to the Nasscom Product Conclave, the discussion on UID and later the RPM talk at the Business Technology Summit at Bangalore next week.

Operational Responsiveness for People

Last week met with a journalist (Dy.Editor, Murali) from a leading business newspaper in India (Hindu Business Line). We talked about many things that are at the top of my mind now- software products, future of IT industry, startups, middleware technology trends and, needless to say, Operational Responsiveness and our Responsive Process Management (RPM) strategy. Like I have been doing a lot lately, highlighted the visibility and control that RPM is enabling in a non-intrusive manner retaining all existing apps & solutions as is and still get the needed visibility across biz processes that span these applications. And get this without re-engineeirng any application. (A promise that has long been made by SOA but something that is not easy to realise without massive re-engineering to get services and automated business processes in place. So first order problems are solved by getting any re-engineering needed in place. But an organization's visibility and control needs are much beyond these first order problems).

As I was engrossed in explaining the value from RPM, this journalist posed a question from a completely different view. Asked if there is any way to track Operational Responsiveness of people? Anyway to get real-time visibility into the people part of the organizations. Not the time-sheet type tracking of who is doing what and for how long- but more of a semantic and collaboration enabling type of tracking. Of trying to capture who is "thinking" about what at any given point. And use this information to trigger collaboration. If I see a colleague of mine is presently thinking about a particular problem area, and I have inputs, I can share it knowing that he/she is going to consider/consume it right away.And do this in an RPM manner, with visibility, alerts and workflows.

Now, this was an interesting thought. I know organizations have been working on knowledge management and collaboration approaches and tools for long. In spite of very widespread penetration of Wikis, networking tools and social style collaboration in organizations, still not easy to realize the collaboration organizations could use. Often different people go thru the solving same problems each solving it again without realising someone has already solved it. Would Operational Responsiveness help here? Can the needed "visibility" into people and what they are presently working on be enabled? And then, build the "responsiveness" and "control" (read, collaboration here) capabilities. This was the gist of the journalists thought. Very interesting. Especially when he brought this up as I was talking about how RPM enables seamless and effortless visibility and control in an organization (essentially machines, applications, business functions, processes and other manifestations of machine processing- but none involving people in the organization and what they are presently thinking about!).

Provisioning Dimensions for the Cloud

At last Saturday's class for my Middleware Internals at IIIT-Hyderabad, I was introducing cloud computing and provisioning. Some basic questions came up - even computer science students from a Top-10 institution in the country have questions like "Isn't SaaS Cloud". What many miss is that Cloud Computing is more about virtualization-over-the-web and the enabling of mechanics such as integration and provisioning.

To this end (virtualization-over-the-web), Software-as-a-Service (SaaS) provides the end users [i.e. the enterprise] value based views of a 'virtualized' application wherein all the operational and infrastructural aspects are managed by the service provider. Likewise PaaS provides the virtualized view of an application platform on which the end user can build a solution. Or with IaaS, where just the infrastructure/OS is virtualized over the web on which any solution can be installed and configured. The definition of cloud also varies based who you ask. Platform-as-a-Service (PaaS) providers will tell you that cloud is when you build applications on their platform. IaaS providers will tell you that if you use their infrastructure, then that is cloud. But I feel the real cloud is what the end enterprises see--a virtualized over-the-web application landscape in a combination of IaaS, PaaS & SaaS. It's a very heterogeneous environment that enables the IT solutions for the various business needs that the enterprise may have. This integrated infrastructure gets the best of breed with no constraints on technologies, platforms, payment models, and even physical location, while still enabling some common binding elements such as Web 2.0 enabled user interface, common administration approach, common integration approach and even provisioning capabilities across the various platforms in the cloud. 

Provisioning is also emerging as an important common aspect of cloud computing. It has emerged from something intrinsic to specific platforms such as Amazon EC2, and now to a more generic expectation across all cloud services.Though the dimensions and approaches to its realization may be different in different providers, a few key dimensions are hardware resources, application platforms or cross cutting dimensions like user provisioning or business service provisioning. Examples include specific resources like hardware (say 2 CPUs), OS (linux ver x.y), app platform (tomcat servlet engine), or an instance of a specific application. And more importantly non physical resources like provisioning a user (for example: enabling access to multiple systems/apps for a new employee).

Through 2010 I think we should be seeing more enabling abstractions, models and utilities for provisioning in the heterogeneous cloud computing environments.

Semantic Web and the Enterprise Integration solutions

A few weeks back I was at the National (Indian) Software Products' conclave at Bangalore. There were a lot of startups that were present. The buzz was amazing (in no small measure due to the presence of Guy Kawasaki and Naeem Zafar). I was able to interact with a lot of startups (good opportunity enabled via the Startups Track that I was co-organizing at the conclave). Among many others, there were two startups that were particularly interesting and both were looking at RDF (the Web3.0 Semantic Web markup standard) use cases in Enterprise solutions - particularly for knowledge management and data mining.

Now coming to think of it, the Web3.0 approach to a semantic web also makes a lot of sense to enterprise data. Both for Intranet content and for business data. For the Intranet, this enables creating a usable 'knowledge' veneer on the static content, wikis, discussion forums and other myriad information sources in enterprise Intranets. A veneer that allows creating semantic linkages and references across these various information sources. And for business data, it will enable creating semantic linkages across business data.

Coincidentally, I came across this article (few years old) on the 'Semantic Integration' of Enterprise reporting data; the data warehouses. Here the emphasis is on SVT (Single Version of Truth), and it recommends having just one data warehouse as the master. Now wouldn't it be nice to extend the paradigm to enterprise data as well? Meaning... the OLTP database is itself the DW as well. This is not entirely unfounded. Informix, the 2nd largest UNIX DB in the 1990s (and since extinct), actually attempted this. They built DW capabilities into the OLTP database, thereby attempting to eliminate the need to have two separate databases.

While a single DB is not possible, an integrated view of the enterprise data that collates all sources is not far fetched. In fact, Progress DataXtend SI actually enables it today. The data exchanges between various applications in the enterprise is a need and reality of today - even more so in the integrated enterprise with extensive use of SOA infrastructure. To this you can add Master Data management. Now while solutions like DataXtend SI do enable a transparent access to various data sources in the enterprise with all semantics of the same modeled and preserved to present a common enterprise view of all data in the enterprise, wouldn't it be nice to extend the same further?

Consider this... with the semantics of various data sources mapped to a common enterprise view, this could be extended to allow dynamic ad hoc querying. And if this is also marked up with RDF meta data that provides linkages across applications, this will also allow semantic querying in Web 3.0 languages like Sparql. Extending this further, one could also look at getting semantic results collating this enterprise results with even sources on the web. For example: this could enable getting results for queries searching all customers that have bought high-value products from the enterprise and have CEOs that are interested in sailing. Now the list of customers is available in the CRM & Order processing system. But the information on who the CEO is may not be in the enterprise DB - this may be on the client companies website. And the fact that the CEO likes sailing may be on a social networking site. Now Web 3.0 will integrate the company site with social networking site and enable this linkage that the CEO likes sailing. And if we enable RDF within the enterprise, then that will enable the full query to find the "customers that have CEOS who like sailing".

At this point, the use case is more academic. (And some work is underway at IIIT-H). But in few years as RDF gets traction and Web3.0 usage picks up, the need for integrating enterprise data also into this semantic search space may follow. And when this occurs, the enterprise model based data integration that DXSI enables will be a strong starting point for such solutions.

Telecom Standards and SOA - Spreading further

The telecommunications industry has been one of the early adopters of SOA infrastructure - given their much higher level of need for integration in general. The complexities are unique with the vibrant M&A activity and a very large number of seriously inter-dependent solutions, aggravated by the hardware solutions that form the solution space. Over the years and as SOA models have evolved, they are now faced with multiple layers of integration, including:

• Services: The primary integration backbone for business functions across the enterprise solution/apps space. (Progress Sonic ESB fits in here very well.)
• Data Integration: By itself for MDM and such, and also for services integration when sending data as inputs for or as returned data from services.  (Progress DataXtend SI is a unique, and probably the only, product that helps here.)
• Management/Governance: Extends problems such as Business Transaction Assurance. (Progress Actional addresses these challenges.)
• Events: Complex BTA and BAM analytics. (Using business events intercepted by Actional, Prorgess Apama can perform more complex correlation and analysis.)

Consistent with the above, Telecom Management Forum (or TM Forum) has defined a plethora of standards that enable telecom Software ISVs, Telecom operators, and SIs to simplify the integration solution space. The Global SIs based out of Asia and the Telecom operators in this region are seeing a rapid uptake of these standards (specifically the SID model).

Reflecting this, NASSCOM (the Indian National software industry association) is organizing a half-day NASSCOM Symposium that will discuss and deliberate on the three facets of emerging telecom industry trends - Standards, Key Business Problems (Transformation and Migration) and case studies. Progress Software (India) is helping organize this event and Michael Aubin, VP focused on Telecom at Progress Software, is delivering a key session on the telecom standards and trends. For more details, visit www.nasscom.in.

Why on-premise SOA cannot offer cloud pricing

David Linthicum suggests that SOA infrastructure vendors must switch to a cloud pricing model and get paid only on delivering value, further taunting the vendors to put their money behind their products. Interesting proposition... But I don't believe it will work. And the comparison to cloud or SaaS may not even be valid. For SaaS, its easy to identify the value delivered - as that of a business solution being made available as a service. For cloud, the SLAs are at the platform level and can only ensure availability - they cannot ensure business value. On-premise SOA is even worse because the operating platform is not even in the SOA vendors control, so guaranteeing even the availability at the same level as cloud is not even possible. At best the vendor can assure that the SOA platform will not fail, but they definitely cannot guarantee against failure from the hardware, OS or other layers in the solution stack that reside with or on the on-premise SOA.

The business value that David refers to is way beyond just platform availability, and that surely cannot be assured by any single component in the overall solution stack - unlike in the SaaS model where the SaaS provider controls the complete solution stack and can provide the guarantees.

Simple SOA. Not-so-simple SOA.

Open Source SOA has arrived! On a single day we have one platform announce that they have simplified basic SOA, and another has announced that SOA is never simple - and if it is simple, just use web services. The question is... is there really a simple SOA and a not-so-simple SOA?

As I look at it, there is a very fine line between simple SOA and the more complex ones that require an enterprise service bus (ESB). Lines are blurred today. Now, ESB itself can be in a single container or more massively distributed ESBs with a strong messaging backbone (like Sonic ESB). But messaging backbone or not is more about the underlying integration infrastructure. So, what does it mean for the application itself? Is the model/paradigm different for the two cases? This is what gets lost out in the melee - the application models and the underlying infrastructure are quite decoupled. From an application standpoint many of the ESB mediation requirements may always be needed functionally. Can one access services without getting the data in the right format? To get it in the right format, won't we need data transformation? And security is a given in all cases. Sometimes one can look at business rules based routing to services. All of these regardless of whether it is a simple SOA or not-so-simple (more distributed multi-data-center) SOA. 

This (common treatment of all SOA use cases regardless of complexity) is very evident with the way our open source platform, FUSE, works because it has an embeddable transport layer. One could use the containers with or without Active MQ. But with or without distribution, the same functionality is available. Simple SOA? Or not?

SaaS, PaaS... why not SOAaaS (SOA as a Service)?

A busy day in the rapidly converging SOA and Cloud worlds. Oracle talks about plans for the cloud, retracting from the skepticism expressed some months back. Intuit announces a PaaS platform. Another SOA infrastructure vendor dabbles with SOA on the cloud - striking dichotomy here. On one hand we are still trying to figure out how exactly to make SOA projects successful. And on the other, we are talking about SOA in the Cloud and PaaS platforms for SOA. Even so, I find it a natural progression.

PaaS, and therefrom the SOA impact, follows the success of SaaS. Which itself was the best thing to happen to ISVs in recent times. A combination of emerging application models, web based software UI approaches, new cloud platforms, and a very wide acceptance of externally hosted software solutions - less of technology and more of mindset. Now it is only a logical extension of the SaaS paradigm that now one will expect to build custom solutions on the web (PaaS). Or host solutions directly on the web based infrastructure (Cloud). And the moment there are applications, SOA cannot be far behind. The nature of the cloud beast is also such that the significance of SOA and distributed management/governance becomes even more critical given the rather loosely coupled and a less-controlled computing environment.

So while enterprises may be OK with having solutions hosted externally on the web/cloud, they may still want the integrated enterprise where these external solutions are seamlessly available in the enterprise integration platform (SOA) and also in the enterprise distributed management and governance platform. We can probably extend these to bring the external apps into the prevailing GRC and BAM framework in the enterprise, so it is only natural that SOA becomes a first class consideration when SaaS/PaaS/Cloud are in the picture.

Not far will be the support for SOA as a primary attribute of cloud platforms. Right off the bat one will have the ability to build and host applications over the web, with the default web based UI models and a very integration ready platform - both for consuming/orchestrating services over the web, and also to expose new services (off this application) over the web.

Now... taking this a bit further, one could look at explicit platforms just FOR integration and SOA!  Even now there are BPM vendors like Cordys that are providing a web based orchestration platforms (PaaS). These can easily be extended to offer a complete services and integration-application platform on the cloud. Only, we need to figure out the use cases where one needs integration off the cloud. Needing SOA as a Service (SOAaaS).

CEP as XTP, in SOA Environments

I have been tracking caching based application platforms such as Gigaspaces for sometime now, and I was surprised to see a new spin on these - as XTP (Extreme Transaction Processing) complimenting SOA. They are extending the caching capabilities to SOA solutions. Labeling this stateful SOA environment as a SOA Grid, and projected as an enabler to build next generation applications are in the areas of fraud detection, trade resolution, and risk management calculations away from the mainframe to low cost commodity hardware. Now, this is exactly the pitch from complex event processing (CEP) environments as well. And even CEP is seen as extending SOA infrastructure to support the capabilities to handle large volume event streams such a the banking or credit-card transaction events, needed for fraud detection.

At some level, the notion of "stateful" SOA grids proposed in the above paper is a contradiction of sorts. SOA is by definition discrete and loosely coupled services environment that are brought together in an orchestration environment to realize required business functions. Products such as Progress Sonic ESB do extend the orchestration capabilities to a more distributed environment (itineraries). Here one can see some value for a distributed state information (that caching products such as Giga and Terracota provide). But expecting this to provide the required capabilities for large volume event stream processing is a real stretch!

For starters, CEP is more than (surely, different from) a fast data-access/query mechanism, which is what caching solutions are. Caching solutions essentially extend the database processing model by providing a faster access to data. While CEP is less about data and much much more about quickly 'reacting' to events and detecting temporal patterns that occur in and across these large volume event streams, combining this within an SOA that can emit the events (based on the biz processing occurring within), or provide the required biz processing after the complex-event is detected, is in itself an XTP environment. It is capable of processing a very large volume of event streams and it needs to detect complex patterns in these streams. And, largely due to the unique approach used in the Progress Apama Correlator engine, it flips the conventional store-and-query approach (which is where caching products come in) to a look-ahead-and-react mode. This has already been proven in some of our successful Apama CEP deployments, such as Algorithmic Trading and Fraud Detection (the very same cases referred in above blog post). See the diagram below to see how Apama CEP works:

SOA Governance in SMEs == Cart Before the Horses

I have always held that SOA governance is premature yet. While we are struggling to just get SOA adoption in the right spirit, governance is the least of our problems. If we cannot identify a mechanism to first re-engineer "service orientation" into IT solutions and have the IT teams in an organization be "SOA aware" ground up and not just deliver the POCs that the CIO or CTO demands, where is the need for operational processes and governance? In this context I found this article that professes a SOA governance approach for SMEs to be quite out of touch with reality.

While the thoughts proposed, such as agile approach to governance and the business users defining the need and IT groups quickly implementing the same, a managed governance process is not necessarily bad. It's just that we are dealing with more fundamental issues right now. Issues that are preventing the widely touted gains of SOA. That led to the drastic predictions of SOAs death!

In the present stage of SOA adoption, where we have just crossed the hype-curve's chasm, and are just now pondering over the serious practical use cases with a full grip on reality (of issues with SOA adoption), all that is immediately needed is anything but SOA Governance. Good tools and utilities to help quickly create services, test services, deploy and manage the same in production. The need for complete SOA lifecycle governance is still a few years away. At least, and surely not for SMEs, their SOA problems will be much more fundamental. SOA Management is what they will need now.

 

SOA Next- Just a New Skin for the Same Problems

After the recent (and dramatic) proclamation that SOA is dead, is it a question of time until we see the rising of the proverbial Phoenix? Seems to be starting... at least going by the interview with Miko Matsumura in Information Week. Referring to the Gartner hype Cycle, he says, "I think we're on the 'Slope of Enlightenment' before we reach the 'Plateau of Productivity'. Anne Thomas Manes' pronouncement about the death of SOA was made in the depths of the 'Trough of Disillusionment'." I particularly liked the reference to "coarse grained cost-cutting", where he says when a whole division is rendered obsolete, what happens to the systems that the division was responsible for; that may still remain operational? SOA infrastructure is supposed to solve this!

Miko's solution is that if the services are well defined - with dependencies clearly modeled and governance practices in place - then it is easy for the organization to deal with such extreme situations as a whole division not existing anymore! This seems like Utopia. Really!

To me, the scenario is more the promise of SOA. The issue though (leading to the proclamation of SOAs death) is the reality, which is far from the promise. None of the anticipated flexibility and value is realized beyond the POCs and pilots! Not much mainstream gains yet. But, like I mentioned in an earlier post, the issue is more about the adoption approaches rather than any inherent deficiencies in the SOA design approaches or the platforms/technologies selected.

So even if we were to invent a "new SOA" or "SOA Next" or "SOA Whatever", the problem will remain because it never was about the technology, per se. It is more about the practical difficulties in getting an organization (its management, architects and developers) to understand and appreciate the SOA principles even half as much as they yap about the next minor revision to a WS* standard as the necessary consideration in their present SOA projects.

At the end of a successful SOA initiative, it's not just about the individual IT groups/teams understanding the need for defining a services layer, it's also about their well defined UI and DB layer which have to be ready for enabling coarse-grained services based on sufficient cross-functional business analysis of the organization. What's more these should be XML-aware layers, beyond just the fringes ("wrappers"). Now, all of these need to be in a single solution, regardless of who needs it now, and what SOA platform is in place. In this bottom-up approach to SOA adoption, the principles are adopted and ingrained first, and then comes the platforms, services, orchestration and governance.

Simply put, successful "service orientation" is the single most significant key to successful SOA in any organization!

Who Needs DW? Welcome, Real-time BI !

Last week I got a last minute invite to speak at the Silicon India BI conference (last minute for a good reason I guess... me & BI? Hmmm... :-) My database background notwithstanding!). Initially I resisted as couldn't think of anything of value, especially because the participants were expected to be architects and senior tech folks. As Pradeep (heads Silicon India) nudged, a thought crossed. I recently also came across a BAM use case where the kind of questions they wanted the solution to answer bordered on BI. And, in this solution they needed both SOA and Complex Event Processing (CEP).

Isn't using CEP for BAM in some form real-time BI? I deliberated for a few minutes - the CEP SOA synergies seemed to really make sense, so I agreed to speak. When asked for the title, I submitted "Design Approaches for Real-time BI".

BAM (business activity monitoring) is an extension of traditional business intelligence; adding event monitoring to scheduled, batch-based reporting. As I see it, BI can be of a few different types (when seen from the tainted SOA lens :-) ):

• Simple BAM is watch ‘as-is’. Most BAM software supports simple aggregation and watches for thresholds, et al.
• Complex BAM can watch for more complex patterns.

At some level isn't complex BAM BI? It provides insight and information that traditional OLTP systems cannot give. For BAM or BI, the discrete steps in the decision cycle are the same: Track/monitor; Analyze; Hypothesize/ model; Decide; and Act . The only difference being that BAM (however sophisticated) may not be able to answer adhoc queries and what-ifs. It can only answer pre-defined and pre-modeled situations. Nevertheless, this is BI. And it is real-time!

SOA and CEP form a good basis for realizing this. Conventional (read 'simple') BAMs may not suffice. BI is more than just thresholds or SLA violation alerts. One may need to detect a pattern involving a series of biz failures that could potentially cause a much serious eventual failure, which if detected and alerted in time, can be averted. This is where more complex pattern recognition come into play. The CEP engine. Given that we are talking about business events from all over the enterprise as the inputs, SOA infrastructure fits right in as the potential vehicle to deliver these events to the CEP engine.

SOA+CEP for real-time BI! An interesting proposition! And surely something traditional DW solutions cannot handle. DW & real-time? Nah. Now, can we extend this basic real-time BI to also include adhoc querying and such? Something to ponder about.

Embedded Not-so-lightweight ESBs

David Linthicum touched upon a very prevalent problem of technology not living up to its expectations set during the hype curve! He says, "With cloud computing, SOA, or whatever we come up with next, we still need to figure out core issues within our enterprises that no set of technologies or emerging trends can solve." In the service-oriented architecture (SOA) case, we all know that the widely professed use cases of systems "automatically" looking up service registries on the web/intranet, locating the required services, getting the interfaces, picking the right one, and actually making a service request is just a pipe dream! The reality is nowhere close! It is difficult to even find enterprise wide service buses, much less the dynamic on-the-fly service-look up-and-use!

I recently came across a scenario where even a large international bank has SOA infrastructure solving regional problems - and not necessarily as a corporate backbone! I was at this tech discussion with the regional technology head of a large bank, exploring how Apama (Progress' Complex Event Processing (CEP) engine) fits into a biz requirement they have. Specifically, he wanted to understand how Apama works and how it is a good fit for their biz problem. They were trying to build a business performance tracking solution (a la GRC) that involves tracking key biz activities, ensure due process is followed, and then proactively detect potential service-level agreement (SLA) failures so they can be averted. A classic use case for Apama!

Now, when we started to see where the business events information came from and how they could be "wired" to emit the required events into Apama, we suggested that they could just tie into their enterprise service bus (ESB)—we knew they had standardized on one. As we dwell further, it turns out they are using an ESB to solve departmental integration requirements, and there are multiple instances and no central ESB that can help integrate these "departmental integrations".

Now that was a revelation. (I am not complaining because suddenly our opportunity now included Sonic ESB, along with Apama). While we have been reading (and I myself have been blogging and talking) about how SOA failed to live up to its expectations, I still expected at least a large number of banks to have standardized backbones. But not to be! I guess, like in many large enterprises, even here SOA adoption has started purely to solve departmental integration problems—more as localized islands of "integration". And its nothing like the enterprise-wide integration platforms or service bus that we have so much noise about since 2004. This reality check at this bank was a clear validation of this failure! It seemed clear that the technology promise was something, and the actual on the ground realization was something totally different!

Come to think of it, it does seem like a good model for use cases such as BAM or GRC - to have a complete platform that in addition to the CEP engine and dashboard, it also includes a "local/embedded" ESB. Now, embedded is not about being lightweight or smallas it is about being available out of the box when you get the platform. In this case, the ESB is available along with CEP, well integrated - so no surprises as you start using it. And the purpose is to "wire" exchanges from existing ESBs or applications in the enterprise to the CEP environment.

Not a bad idea at all! Embedded ESBs!

SOA and Events - Two Sides of BAM?

I came across a prospect recently (new markets so engineering help is always welcomed :-) ) - a domain consulting company now building a Governance Risk and Compliance (GRC) solution. Now, this very much being in the area of BAM, one would expect that traditional Business Activity Monitoring (BAM) would be used. But as we were discussing it more, it turns out that more often than not, GRC is about triggering the risk assessment and compliance/governance checks as business events occur. Here again, the trite assumption (that even I made) is that the organization has SOA imbibed all over and so it can easily tie in BAM and use that BAM environment to 'detect' and trigger the necessary checks/rules. And here again, I was proven wrong because SOA is not as widely prevalent as we all would like to believe! The consulting company, a group with a strong domain expertise in Governance & Risk/Performance, who is building the solution said they wanted an "extremely loose" integration, but their prospects were unlikely to have a mature SOA infrastructure. Which means, they cannot really expect BAM to be practical.

After looking at the biz analysis they had already performed, and taking the time to breakdown the GRC system into a bunch of flow-charts (one for each scenario), they found a pattern:

• a business event occurs as part of ongoing business processing
• the event includes the relevant business data
• a series of GRC checks and rules are executed
• any violation is recorded and an alert raised

This consulting company has gone a step further and also modeled the whole biz domain (they were targeting a specific sector in the financial space) - in a very interesting manner. As a set of key business events, anyone in the domain can immediately understand what each of these events mean. Each business event includes a clear definition of the accompanying data. In effect, they flipped the complete domain business ops as a set of business events! Hmmm...

So far, we have seen models that show the enterprise as a bunch of business processes that invoke a set of services. With the above flipped view, the enterprise modeled as a bunch of biz events is very unique. The former is a view of defining the business flows (processes) that form the enterprise's biz processing. The latter view is more of a snapshot of the enterprise post the fact - as business events that "occur" in the enterprise. Both very clearly model the purpose and the data involved, but in the former method, it is the data that flows through. And with the latter approach, the data that gets "generated" post a business activity.

From this consulting company's point of view, modeling the enterprise as a set of business events and the data that each event emanates was a more practical view. The communication to their clients was that they have modeled the GRC flow for each of these biz events. And the integration of the GRC solution involved the client's IT team "wiring" in these events into their existing solutions - wherever the said business activity occurs, and in any technology they may have, SOA or no SOA.  When they wire this, they will also need to pull out the data from their existing systems and "emit" the same as per the defined event data structure.

Pretty neat idea! Is anyone else seeing it this way? Is a GRC solution more about events and less about SOA? Is SOA primary and events incidental, or are events primary and the SOA infrastructure that could generate this be incidental?

SOA - Wanted! Dead or Alive

Burton group's Anne Thomas wrote an obituary  for SOA, and she writes: "SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”."

While this is dramatizing a bit, it is not entirely without merit. I have always wondered where exactly are the SOA use cases. In the real world (beyond the POCs, CTO proposals and pilots), time and time again I come across cases where someone in an organization bemoans that the promise of SOA was never delivered! A very rosy picture was shown during the POC and pilots, but post that, in the real world, the gains realized are nowhere close!

Yesterday, I was at a "SOA - past, present & future" panel discussion in Bangalore, along with SOA Matrix CEO and Head of the Java and middleware horizontal at Satyam. We spent most part of the hour talking about precisely this! Recognizing that mainstream acceptance is not as wide as expected, we were deliberating on the possible reasons. One consensus that emerged is that the complexity is not so much in the paradigms, technology nor the products. The biggest challenge is getting the required functionality at the right granularity, and this is more about the existing solutions in the enterprise than it is about SOA. Re-engineering the solution to "expose" the functionality with a coarse grain is never easy. Often the incumbent applications would be those with just a UI interface. In such applications, as we all know, the tier separations are not that rigidly maintained. A good amount of functionality spans the presentation and functional tiers. Trying to re-engineer this and create a single coarse grained function for the required service is not going to be easy at all! If this is the case for a single service, imagine the magnitude if the problem is one must get hundreds of key business functions "exposed" as services. (And without these hundreds, one cannot even begin to realize the dynamic enterprise promised by SOA, with easy to compose business processes, BAM on-demand, and more.)

Now, I can't imagine how any amount of technology can solve the above problem?

In this context it is interesting to see a pragmatic narrower view of the cloud as proposed by David Linthicum - SOA morphing into private clouds, or as a subset of the whole enterprise or the larger public cloud, as put forth by Mikael Ricknäs of IDG News service. Thankfully, ZapThink MD quantifies the reality realistically; as quoted in ITWeb: "People are asking the right questions about governance, loose coupling, best practices and business agility, one of the major benefits SOA confers," says Bloomberg. "And they're asking the right questions up-front, seeking to solve a business problem rather than adopting SOA for SOA's sake."

For more perspective on Anne's post, read my colleague Dan Foody's post, Goodbye SOA, we hardly knew you., or listen to his podcast, Cloud Computing - The New SOA?

Cloud Computing... It Depends on Who You Ask

What exactly is cloud computing? Lately, this is one of the most often repeated question in any discussion about the Cloud. And the answer depends on who you ask! (Personally, I think that if there are not at least three different popular definitions of a new technology, then the technology is not in its "hype" phase of the hype cycle :-) ).

Cloud is often confused to be just one of:

• Utility Computing - The on-demand resources with dynamic provision offered by virtualization platforms such as VMware, EC2 etc.
• Grid computing - Loosely coupled discreet computing nodes, that come together to form a larger computing-grid.
• SaaS - Just the notion of a software abstracted on the web is cloud to some.
• PaaS - To some, cloud is if one were to "build" the solution and then deploy it on a virtualized platform on the web.
• User centric cloud - RIA desktops that provide seamless and integrated access to information and services on the web, while still retaining a "sane" visual front to the user.
• Even Wikipedia defines it as: The majority of cloud computing infrastructure as of 2009 consists of reliable services delivered through data centers and built on servers with different levels of virtualizationtechnologies. The services are accessible anywhere in the world, with The Cloud appearing as a single point of access for all the computing needs of consumers.
• And, I am sure there are more!

Syscon attempted to reconcile the definitions by getting no less than twenty one (!!) industry experts to define cloud. Their definitions had wide ranging defining attributes: elastic, virtualized, services over the web, multi-tenanted, pay-as-you-use, massively scalable technology enabled services, SaaS is the consumer-face of cloud computing, distributed utility grid (wow!), on-demand resources with APIs, and more!

What I see missing though is the end enterprise view. It is this view that brings all of the above (and more) together. As I see it, this is "cloud computing". A fairly abstract IT enterprise landscape. Where the biz requirement is real—with its solution made available over the web, with simple web based user access, with guaranteed SLAs on service availability and performance, with seamless integration to other information sources/services over the landscape. The exact location, platform, configuration, size and such are all abstracted from the enterprise by the solution provider. Further, the solution provider also takes care of maintaining the application (enhancements/bug fixes), managing the production environment, and managing any backend integration requirements that the client-enterprise may have - offering a complete "managed service". The enterprise needs to focus just on the biz at hand, and in defining the IT solution that is needed. The solution-service providers takes care of the rest. All of them coming together to form the enterprise "cloud" - accessed over the web, managed over the web and probably even orchestrated over the web.

The enterprise Cloud will also evolve over time. When there is just one ISV making a solution available in the above managed model, that is SaaS. If the same ISV also "builds" it on the web before making it available on the web, then that is PaaS. If the ISV just uses storage on the web, then that is cloud storage. If the same solution is deployed within the enterprise network on a virtualized platform such as VMware, then that is virtualization. If the solution is distributed across discreet computing "nodes" on the web, then that will be the computing grids. Now fast-forward a few years... If the IT landscape in an enterprise architecture is a combination of all of the above types of solution environments, then there is an opportunity for a loose "biz grid" that can bring all of these together, which in many ways is already prevalent today - the SOA infrastructure! SOA is all about discreet services that are location agnostic, with standards based description and easy access. Today's SOA environments are very very vendor dependent (that is assuming the emphasis is on the reliability and performance). Soon we may see this a reality. A vendor neutral SOA environment that will bring together all the disparate IT solutions in the enterprise, both within and on the cloud. Likewise, Web 2.0 will define the user experience that brings all of the same solutions in a seamless integrated and very-functional UI.

Below is a visual of what I'm thinking... use Comments to let me know what you think.

Convergence of SaaS, Cloud and SOA - Use Case

Was at the HeadStart (innovation showcase) and Compute (ACM Bangalore chapter) co-event this weekend at Bangalore. Was chairing the panel discussion on "Delivering SaaS from the Clouds". The panel included the Founder/CEO of Computational research Labs (part of TATA goup), Head of Cisco/Webex in India (they have a large dev center and equally large India sales ops), Lead Architect at Honeywell, and the Head of the RIA tools development at Adobe. There were an interesting mix of perspectives ranging from the glue and access paradigms from the fringes of the cloud (as in the RIA & webex rich desktops), to hard core grid paradigms and application/service abstractions on the cloud (bright by CRL), to cloud backends (CRL and Webex) and the usage perspective brought on by Honeywell exploring cloud for many of its field initiatives. We also had great discussions ranging from the market opportunities that each one sees to their take on the solution architectures and to the cloud trends that we can expect in 2009.

In particular, I found two aspects very interesting:

1. Build-on-desktop or Build-on-cloud? Unlike the more popular expectations of using the cloud to "host" applications that are built on desktops and 'uploaded' to the clouds to be accessed from browsers, there are also models (in industrial automation) where the application is built on the cloud and 'downloaded' to the devices. Essentially, they are engineered on cloud and downloaded to the devices in the enterprise - examples include energy audits and automation optimizations.
2. The serious production use cases are still elusive. Most people dabbling in cloud are still experimenting and playing around with it. Serious use models are yet to evolve. I believe that this is probably a manifestation of the hype curve. Hopefully the dust will settle down and serious usage emerges in 2009.

Talking about use cases, I came across another interesting use case in the same week. This is in the Governance risk and Compliance (GRC) space. Here the value proposition seen from the cloud is unique—beyond just SaaS. In terms of the agility and the arms-length distance:

The GRC space is extremely regulation driven. And is bound to change often. Today the model for implementing GRC is to "build it in" the existing operational solutions, which we all know is cumbersome and extremely difficult to manage changes. Given this, the proposition from this  company was unique. This company that specializes in governance and consults in best practices, has evolved a "canned" GRC model, and is offering the same as SaaS on the cloud. The compelling case to the clients is that this implicitly allows an arms-length distance between operational systems, easy verifiability of the GRC rules in effect, and is also able to easily modify the GRC rules as they evolve and change. The nature of this scenario is implicitly that of convergence. The value prop is SaaS - the runtime is the cloud and the solution involves extensive access to data and services in the enterprise which is best done using an SOA infrastructure.

Come to think of it, cloud in the enterprise will be deeply entwined with SOA. We are not talking about simple utilities like rate calculators or converters. If serious enterprise solutions are made available on the cloud by 3rd parties, these will always involve access to other enterprise information and services running either in the Intranet or possibly elsewhere in the web-cloud as well. So far, any SaaS solution provides for custom APIs to enable this integration. As the more generic cloud platform evolves, it becomes a question of time and the standards and generic approaches to integrate the enterprise into the cloud will emerge.

This will be yet another space to watch in 2009, even as we already are tracking aspects such as cloud performance, and the cloud monitoring and management (an extension of the SOA Management problem that Progress Software already solves very well with Actional).

Do we really need this complexity?

My first post on the Progress SOA Blog! This gives me jitters... All the writing till now was somehow different. There was a carefree attitude to that writing. When I wrote my book (nearly 40% of the book on SOA approach to Integration), or when I write my personal blog posts, I never had to worry about the impact. Now as informal as this may be, at the end of the day it does have a non-personal tone. Even so, I am excited about this. :-)

My views essentially are reflections on the software services and SI ecosystem and what/how they use technologies in the integration solutions space. Lately, I have been also quite caught by the SaaS/PaaS promise in the SOA context - even if I am quite skeptical about the hyped up value.

Recently, I was speaking on this topic at the IndicThreads conference on Java at Pune. I included a slide on the complexity of SOA. While in my flow I was using it to talk about some of the SOA enablers in our SOA portfolio in simplifying this complexity, the presentation and some following questions triggered a thought... How much of this does the industry actually need? Aren’t these more of a fringe scenario that needs all of this? Isn’t the REST vs. SOAP argument a good case in point? 80+% of the world needs only basic remote service mechanism. While REST more than suffices here, this basic need from the world is but just a small part of SOAP! So, who needs the rest?

The simplicity of REST is stark - at least when compared to the extremely unwieldy SOAP and its numerous accompanying specifications. And it is further compounded by all the WS* standards. Making things worse are frameworks for frameworks such as WS-Policy. WS-policy is a framework that layers on SOAP. And there are other standards that use WS-Policy as the basis for definition. In effect, we have XML over HTTP, on which is defined the SOAP standard, on SOA is the WS-Policy. And on WS-Policy are standards such as WS-S & WS-T. Phew!

Now compare this with REST - that actually has no other specification other than HTTP itself! Granted, this seriously limits what we can do with REST. But lets accept it - the world needs mostly ONLY the likes of just REST and only a very small fraction needs the multiple layers of specifications such as SOAP! Even in the SOAP land this is very well captured in how AXIS evolved - trying to keep pace with the rather haphazard offshoots of SOAP. And now there is CXF whose basic premise is to simplify SOAP and Web Services. From the word go, it has embraced the simplicity and is also trying to be more about services and less about SOAP. In the spirit of the latter, CXF also supports REST right off the bat.

I see 2009 as year where this simplicity is bound to get consolidated. The more simpler and easier the SOA framework becomes, the more it will get accepted. FUSE open sources SOA framework will be one very serious contender in this space. Functionally as complete as any other SOA solution, yet lean and mean with a good set of tools. Watch out for more in the months to come.