Category: Enterprise Java
November 18th, 2009
IBM feels cozy on sidelines as Oracle-Sun deal languishes in anti-trust purgatory
You have to know when to hold them, and when to fold them. That’s the not just slightly smug assessment by IBM executives as they reflect — with twinkles in their eyes — on the months-stalled Oracle acquisition of Sun Microsystems, a deal that IBM initially sought but then declined earlier this year.
Chatting over drinks at the end of day one of the Software Analyst Connect 2009 conference in Stamford, Conn., IBM Senior Vice President and IBM Software Group Executive Steve Mills told me last night he thinks the Oracle-Sun deal will go through, but it won’t necessarily be worth $9.50 a share to Oracle when it does.
“He (Oracle Chairman Larry Ellison) didn’t understand the hardware business. It’s a very different business from software,” said Mills.
Mills seemed very much at ease with IBM’s late-date jilt of Sun (Sun was apparently playing hard to get in order to get more than $9.40/share from Big Blue’s coffers). IBM’s stock price these days is homing in on $130, quite a nice turn of events given the global economy.
Sun is trading at $8.70, a significant discount to Oracle’s $9.50 bid, reflecting investor worries about the fate of the deal now under scrutiny by European regulators, Mill’s views notwithstanding.
IBM Software Group Vice President of Emerging Technology Rod Smith noted the irony — perhaps ancient Greek tragedy-caliber irony — that a low market share open source product is holding up the biggest commercial transaction of Sun’s history. “That open source stuff is tricky on who actually makes money and how much,” Smith chorused.
Should Mills’s prediction that Oracle successfully maintains its bid for Sun prove incorrect, it could mean bankruptcy for Sun. And that may mean many of Sun’s considerable intellectual property assets would go at fire-sale prices to … perhaps a few piecemeal bidders, including IBM. Smith just smiled, easily shrugging off the chill (socks in tact) from the towering “IBM” logo ice sculpture a few steps away.
And wouldn’t this hold up go away if Sun and/or Oracle jettisoned MySQL? Is it pride or hubris that makes a deal sour for one mere grape? Was the deal (and $7.4 billion) all about MySQL? Hardly.
Many observers think that Sun’s Java technology — and not its MySQL open source database franchise — should be of primary concern to European (and U.S.) anti-trust mandarins. I have to agree. But Mills isn’t too concerned with Oracle’s probable iron-grip on Java …, err licensing. IBM has a long-term license on the technology, the renewal of which is many years out. “We have plenty of time,” said Mills.
Yes, plenty of time to make Apache Harmony a Java doppelganger — not to mention the Java market-soothing effects of OSGi and Eclipse RCP. [Hey, IBM invented Java for the server for Sun, it can re-invent it for something else ... SAP?]
Unlike some software titans, Mills is clearly not living in a “reality distortion field” when it comes to Oracle’s situation.
“We’re in this for the long haul,” said Mills, noting that he and IBM have have been competing with Oracle since August 1993 when IBM launched its distributed DB2 product. “All of our market share comes at the expense of Oracle’s,” said Mills. “And we love to do benchmarks again Oracle.”
Even as the Fates seem to be on IBM’s side nowadays, the stakes remain high for the users of these high-end database technologies and products. It’s my contention that we’re only now entering the true data-driven decade. And all that data needs to run somewhere. And it’s not going to be in MySQL, no matter who ends up owning it.
November 3rd, 2009
Survey: Virtualization and physical infrastructures need to be managed in tandem
If your company uses test and development infrastructures as a proving ground for shared services, virtualization and private cloud environments, you’re not alone. More companies are moving in that direction, according to a Taneja Group survey.
Yet underlying the use of the newer infrastructure approaches lies a budding challenge. The recent Taneja Group survey of senior IT managers working on test/dev infrastructures at North American firms found that 72 percent of respondents said virtualization on its own doesn’t address their most important test/dev infrastructure challenges. Some 55 percent rate managing both virtual and physical resources as having a high or medium impact on their success. The market is clearly looking for ways to bridge this gap.
Sharing physical and virtual infrastructures
Despite the confusion in the market about the economics of the various flavors of cloud computing, Dave Bartoletti, a senior analyst and consultant at Taneja Group, says one thing is clear: Enterprises are comfortable with, and actively sharing, both physical and virtual infrastructures internally.
“This survey reaffirms that shared infrastructure is common in test/dev environments and also reveals it’s increasingly being deployed for production workloads,” Bartoletti says. “Virtualization is seen as a key enabling technology. But on its own it does not address the most important operational and management challenges in a shared infrastructure.”
Half the survey respondents are funding projects starts in 2009. Another 66 percent of respondents will have funded a project started by the end of 2010.
Noteworthy is the fact that 92 percent of test/dev operations are using shared infrastructures, and companies are making significant investments in infrastructure-sharing initiatives to address the operational and budgetary challenges. Half the survey respondents are funding projects in 2009. Another 66 percent of respondents will have funded a project started by the end of 2010.
The survey reveals most firms are turning to private cloud infrastructures to support test/dev projects, and that shared infrastructures are beginning to bridge the gap between pre-production and production silos. A full 30 percent are sharing resource pools between both test/dev and production applications. This indicates a rising comfort level with sharing infrastructure within IT departments.
Virtualization’s cost and control issues
Although 89 percent of respondents use virtualization for test/dev, more than half have virtualized less than 25 percent of their servers. That’s because virtualization adds several layers of control and cost issues that need to be addressed by sharing, process, workflow and other management capabilities in order to fully maximize and integrate both virtual and physical infrastructures.
“Test/Dev environments are one of the most logical places for organizations to begin implementing private clouds and prove the benefits of a more elastic, self service, pay-per-use service delivery model,” says Martin Harris, director Product Management at Platform Computing. “We’ve certainly seen this trend among our own customers and have found that additional management tools enabling private clouds are required to effectively improve business service levels and address cost cutting initiatives.” [Disclosure: Platform Computing is a sponsor of BriefingsDirect podcasts.]
Despite the heavy internal investments, however, 82 percent of respondents are not using hosted environments outside their own firewalls. The top barriers to adoption: Lack of control and immature technology.
BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post.
November 3rd, 2009
You'll be far better off in a future without enterprise software
This guest post comes courtesy of Ronald Schmelzer, senior analyst at ZapThink.
By Ronald Schmelzer
The conversation about the role and future of enterprise software is a continuous undercurrent in the service oriented architecture (SOA) conversation. Indeed, ZapThink’s been talking about the future of enterprise software in one way or another for years.
So, why bother bringing up this topic again, at this juncture? Has anything changed in the marketplace? Can we learn something new about where enterprise software is heading? The answer is decidedly “yes” to the latter two questions. And this might be the right time to seriously consider acting on the very things we’ve been talking about for a while.
The first major factor is significant consolidation in the marketplace for enterprise software. While a decade or so ago there were a few dozen large and established providers of different sorts of enterprise software packages, there are now just a handful of large providers, with a smattering more for industry-specific niches.
We can thank aggressive M&A activity combined with downward IT spending pressure for this reality. As a result of this consolidation, many large enterprise software packages (such as enterprise resource planning (ERP), customer relationship management (CRM), supply chain management (SCM) offerings) have been eliminated, are in the process of being phased out, or are getting merged (or “fused”) with other solutions.
Many companies rationalized the spending of millions of dollars on enterprise software applications because the costs could be amortized over a decade or more of usage, and they could claim that these enterprise software applications would be cheaper, in the long run, than building and managing their existing custom code. But, we’ve now had a long enough track record to realize that the result of mass consolidation, need for continuous spending, and inflexibility is causing many companies to reconsider that rationalization.
We can thank expensive, cumbersome, and tightly-coupled customization, integration, and development for this lack of innovation in enterprise software.
Furthermore, by virtue of their weight, significance in the enterprise environment, and astounding complexity, enterprise software solutions are much slower to adopt and adapt to new technologies that continuously change the face of IT.
We refer to this as the “enterprise digital divide.” You get one IT user experience when you are at home and use the Web, personal computing, and mobile devices and applications and a profoundly worse experience when you are at work. It’s as if the applications you use at work are a full decade behind the innovations that are now commonplace in the consumer environment. We can thank expensive, cumbersome, and tightly coupled customization, integration, and development for this lack of innovation in enterprise software.
In addition, no company can purchase and implement an enterprise software solution “out of the box.” Not only does a company need to spend significant money customizing and integrating their enterprise software solutions, but they often spend significant amounts of money on custom applications that tie into and depend on the software.
What might seem to be discrete enterprise software applications are really tangled masses of single-vendor functionality, tightly-coupled customizations and integrations, and custom code tied into this motley mess. In fact, when we ask people to describe their enterprise architecture (EA), they often point to the gnarly mess of enterprise software they purchased, customized, and maintain. That’s not EA. That’s an ugly baby only a mother could love.
Yet, companies constantly share with us their complete dependence on a handful of applications for their daily operation. Imagine what would happen at any large business if you were to shut down their single-vendor ERP, CRM, or SCM solutions. Business would grind to a halt.
While some would insist on the necessity of single-vendor, commercial enterprise software solutions as a result, we would instead assert how remarkably insane it is for companies to have such a single point of failure. Dependence on a single product, single vendor for the entirety of a company’s operations is absolutely ludicrous in an IT environment where there’s no technological reason to have such dependencies. The more you depend on one thing for your success, the less you are able to control your future. Innovation itself hangs in the balance when a company becomes so dependent on another company’s ability to innovate. And given the relentless pace of innovation, we see huge warning signs.
Services, clouds, and mashups: Why buy enterprise software?
In previous ZapFlashes, we talked about how the emergence of services at a range of disparate levels combined with evolutions in location- and platform-independent, on-demand, and variable provisioning enabled by clouds, and rich technologies to facilitate simple and rapid service composition will change the way companies conceive of, build, and manage applications.
Instead of an application as something that’s bought, customized, and integrated, the application itself is the instantaneous snapshot of how the various services are composed together to meet user needs. From this perspective, enterprise software is not what you buy, but what you do with what you have.
One outcome of this perspective on enterprise software is that companies can shift their spending from enterprise software licenses and maintenance (which eats up a significant chunk of IT budgets) to service development, consumption, and composition.
This is not just a philosophical difference. This is a real difference. While it is certainly true that services expose existing capabilities, and therefore you still need those existing capabilities when you build services, moving to SOA means that you are rewarded for exposing functionality you already have.
Whereas traditional enterprise software applications penalize legacy because of the inherent cost of integrating with it, moving to SOA inherently rewards legacy because you don’t need to build twice what you already have. In this vein, if you already have what you need because you bought it from a vendor, keep it – but don’t spend more money on that same functionality. Rather, spend money exposing and consuming it to meet new needs. This is the purview of good enterprise architecture, not good enterprise software.
When you ask these people to show you their enterprise software, they’ll simply point at their collection of Services, Cloud-based applications, and composition infrastructure.
The resultant combination of legacy service exposure, third-party service consumption, and the cloud (x-as-a-service) has motivated the thinking that if you don’t already have a single-vendor enterprise software suite, you probably don’t need one.
We’ve had first-hand experience with new companies that have started and grown operations to multiple millions of dollars without buying a penny of enterprise software. Likewise, we’ve seen billion-dollar companies dump existing enterprise software investments or start divisions and operations in new countries without extending their existing enterprise software licenses. When you ask these people to show you their enterprise software, they’ll simply point at their collection of services, cloud-based applications, and composition infrastructure.
Some might insist that cloud-based applications and so-called software-as-a-service (SaaS) applications are simply monolithic enterprise software applications deployed using someone else’s infrastructure. While that might have been the case for the application service provider (ASP) and SaaS applications of the past, that is not the case anymore. Whole ecosystems of loosely-coupled service offerings have evolved in the past decade to value-add these environments, which look more like catalogs of service capabilities and less like monolithic applications.
Want to build a website and capture lead data? No problem — just get the right service from Salesforce.com or your provider of choice and compose it using web services or REST or your standards-based approach of choice. And you didn’t incur thousands or millions of dollars to do that.
Open source vs. commercial vs. build your own
Another trend pointing to the stalling of enterprise software growth is the emergence of open source alternatives. Companies now are flocking to solutions such as WebERP, SugarCRM Community Edition, and other no-license and no-maintenance fee solutions that provide 80% of the required functionality of commercial suites.
While some might point at the cost of support for these offerings, we point out the factor of difference between support and license/maintenance costs. At the very least, you know what you’re paying for. It’s hard to justify spending millions of dollars in license fees when you’re using 10% or less of a product’s capabilities.
Enhancing this open source value proposition is that others are building capabilities on top of those solutions and giving those solutions away as well. The very nature of open source enables creation of capabilities that further value-adds a product suite. At some point, a given open source solution reaches a tipping point where the volume of enhancements far outweighs what any commercial vendor can offer. Simply put, when a community supports an open source effort, the result can out-innovate any commercial solution.
There are now a lot of pieces and parts available that are free, cheap, or low cost that companies can assemble into not only workable, but scalable offerings that can compete with many commercial offerings.
Beyond open source, commercial, and SaaS-cum-cloud offerings, companies have a credible choice in building their own enterprise software application. There are now a lot of pieces and parts available that are free, cheap, or low cost that companies can assemble into not only workable, but scalable offerings that can compete with many commercial offerings. In much the same way that companies leveraged Microsoft’s Visual Basic to build applications using the thousands of free or cheap widgets and controls built by the legions of developers, so too are we seeing a movement to free or cheap Service widgets that can enable remarkably complex and robust applications.
The future of commercial enterprise software applications
It is not clear where commercial enterprise software applications go from here. Surely, we don’t see companies tearing out their entrenched solutions any time soon, but likewise, we don’t see much reason for expansion in enterprise software sales either.
In some ways, enterprise software has become every bit the legacy they sought to replace in mainframe applications that still exist in abundance in the enterprise. Smart enterprise software vendors realize that they have to get out of the application business altogether and focus on selling composable service widgets. These firms, however, don’t want to innovate their way out of business. As such, they don’t want to just provide the trains to get you from place to place, but they want to own the tracks as well.
The question is: Is the cost of the proprietary runtime infrastructure you are getting with those widgets worth the cost?
In many ways, this idea of enterprise software-as-a-platform is really just a shell game. Instead of spending millions on a specific application, you’re instead spending millions on an infrastructure that comes with some pre-configured widgets. The question is: Is the cost of the proprietary runtime infrastructure you are getting with those widgets worth the cost? Have you lost some measure of loose coupling in exchange for a “single throat to choke?”
Much of the enterprise software market is heading in direct collision course with middleware vendors who never wanted to enter the application market. As enterprise software vendors start seeing their runtime platform as the defensible position, they will start conflicting with EA strategies that seek to remove their single-vendor dependence.
We see this as the area of greatest tension in the next few years. Do you want to be in control of your infrastructure and have choice, or do you want to resign your infrastructure to the control of a single vendor, who might be one merger or stumble away from non-existence or irrelevance?
The ZapThink take
We hope to use this ZapFlash to call out the ridiculousness of multi-million dollar “applications” that cost millions more to customize to do a fraction of what you need. In an era of continued financial pressure, the last thing companies should do is invest more in technology conceived of in the 1970s, matured in the 1990s, and incrementally made worse since then.
The reliance on single-vendor mammoth enterprise software packages is not helping, but rather hurting the movement to loosely coupled, agile, composition-centric heterogeneous SOA. Now is the time for companies to pull up the stakes and reconsider their huge enterprise software investments in favor of the sort of real enterprise architecture that cares little about buying things en masse and customizing those solutions — but instead to building, composing, and reusing what you need iteratively to respond to continuous change.
As if to prove a point, SAP stock recently slid almost 10% on missed earnings. Some may blame the overall state of the economy, but we point to the writing on the wall: All the enterprise software that could be sold has been sold, and the reasons for buying or implementing new licenses are few and far between. Invest in enterprise architecture over enterprise software, services over customizations, and clouds over costly and unpredictable infrastructure — and you’ll be better off.
This guest post comes courtesy of Ronald Schmelzer, senior analyst at ZapThink.
SOA and EA Training, Certification,
and Networking Events
In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
October 25th, 2009
Application transformation case study targets enterprise bottom line with eye-popping ROI
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Hewlett-Packard.
This podcast is the first in the series of three to examine Application Transformation: Getting to the Bottom Line. Through a case study, we’ll discuss the rationale and likely returns of assessing the true role and character of legacy applications, and then assess the true paybacks from modernization.
The ongoing impact of the reset economy is putting more emphasis on lean IT — of identifying and eliminating waste across the data-center landscape. The top candidates, on several levels, are the silo-architected legacy applications and the aging IT systems that support them.
Using our case study, we’ll also uncover a number of proven strategies on how to innovatively architect legacy applications for transformation and for improved technical, economic, and productivity outcomes. The podcasts coincidentally run in support of HP virtual conferences on the same subjects:
Register here to attend the Asia Pacific event on Nov. 3. Register here to attend the EMEA event on Nov. 4. Register here to attend the Americas event on Nov. 5.
Here to start us off on our series on the how and why of transforming legacy enterprise applications are Paul Evans, worldwide marketing lead on Applications Transformation at HP, and Luc Vogeleer, CTO for Application Modernization Practice in HP Enterprise Services. The discussion is moderated be me, Dana Gardner, principal analyst at Interarbor Solutions.
Here are some excerpts:
Evans: When the economic situation hit really hard, we definitely saw customers retreat, and basi
cally say, “We don’t know what to do now. Some of us have never been in this position before in a recessionary environment, seeing IT budgets reduce considerably.”
That wasn’t surprising. … It was obvious that people would retrench and then scratch their heads and say, “Now what do we do?”
Now we’re seeing a different dynamic, … something like a two-fold increase in what you might call “customer interest” [in applications transformation]. The number of opportunities we’re seeing as a company has doubled over the last six or nine months.
If you ask any CIO or IT head, “Is application transformation something you want to do,” the answer is, “No, not really.” It’s like tidying your garage at home. You know you should do it, but you don’t really want to do it. You know that you benefit, but you still don’t want to do it.
This has moved from being something that maybe I should do to something that I have to do, because there are two real forces here. One is the force that says, “If I don’t continue to innovate and differentiate, I go out of business, because my competitors are doing that.” If I believe the economy doesn’t allow me to stand still, then I’ve got it wrong. So, I have to continue to move forward.
Secondly, I have to reduce the amount of money I spend on my innovation, but at the same time I need a bigger payback. I’ve got to reduce the cost of IT. Now, with 80 percent of my budget being dedicated to maintenance, that doesn’t move my business forward. So, the strategic goal is, I want to flip the ratio.
… Today, we’ll hear about a case study — with the Italian Ministry of Instruction, University and Research (MIUR). This customer received an ROI in 18 months. In 18 months, the savings they had made — and this runs into millions of dollars — had been paid for. Their new system, in under 18 months, paid for itself. After that, it was pure money to the bottom-line.
… Our job is to minimize that risk by exposing them to customers who have done it before. They can view those best-case scenarios and understand what to do and what not to do.
Vogeleer: We take a very holistic approach and look at the entire portfolio of applications from a custom
er. Then, from that application portfolio — depending on the usage of the application, the business criticality of the application, as well as the frequency of changes that this application requires — we deploy different strategies for each application.
We not only focus on one approach of completely re-writing or re-platforming the application or replacing the application with a package, but we go for a combination of all those elements. By doing a complete portfolio assessment, as a first step into the customer legacy application landscape, we’re able to bring out a complete road map to conduct this transformation.
We first execute applications that bring a quick ROI. We first execute quick wins and the ROI and the benefits from those quick wins are immediately reinvested for continuing the transformation. So, transformation is not just one project. It’s not just one shot. It’s a continuous program over time, where all the legacy applications are progressively migrated into a more agile and cost-effective platform.
The Italian Ministry of Instruction, University and Research (MIUR), is the customer we’re going to cover with this case, is a large governmental organization and their overall budget is €55 billion.
This Italian public education sector serves 8 million students from 40,000 schools, and the schools are located across the country in more than 10,000 locations, with each of those locations connected to the information system provided by the ministry.
Very large employer
The ministry is, in fact, one of the largest employers in the world, with over one million employees. Its system manages both permanent and temporary employees, like teachers and substitutes, and the administrative employees. It also supports the ministry users, about 7,000 or 8,000 school employees. It’s a very large employer with a large number of users connected across the country.
Why do they need to modernize their environment? In fact, their system was written in the early 1980s on IBM mainframe architecture. In early 2000, there was a substantial change in Italian legislation, which was called so-called a Devolution Law. The Devolution Law was about more decentralization of their process to school level and also to move the administration processes from the central ministry level into the regions, and there are 20 different regions in Italy.
This change implied a completely different process workflow within their information systems. To fulfill the changes, the legacy approach was very time-consuming and inappropriate. A number of strong application have been developed incrementally to fulfill those new organizational requirements, but very quickly this became completely unmanageable and inflexible. The aging legacy systems were expected to be changed quickly.
In addition to the element of agility to change application to meet the new legislation requirement, the cost in that context went completely out of control. So, the simple, most important objective of the modernization was to design and implement a new architecture that could reduce cost and provide a more flexible and agile infrastructure.
The first step we took was to develop a modernization road map that took into account the organizational change requirements, using our service offering, which is the application portfolio assessment.
From the standard engagement that we can offer to a customer, we did an analysis of the complete set of applications and associated data assets from multiple perspectives. We looked at it from a financial perspective, a business perspective, functionality and the technical perspective.
From those different dimensions, we could make the right decision on each application. The application portfolio assessment ensured that the client’s business context and strategic drivers were understood, before commencing a modernization strategy for a given application in the portfolio.
A business case was developed for modernizing each application, an approach that was personalized for each group of applications and was appropriate to the current situation.
… This assessment phase took about three months with the seven people. From there, we did a first transformation pilot, with a small staff of people in three months.
After the pilot, we went into the complete transform and user-acceptance test, and after an additional year, 90 percent of the transformation was completed. In the transformation, we had about 3,500 batch processes. We had the transformation. We had re-architecting of 7,500 programs. And, all the screens were also transformed. But, that was a larger effort with a team of about 50 people over one year.
… We tried to use automated conversion, especially for non-critical programs, where they’re not frequently changed. That represented 60 percent of the code. This code could be then immediately transferred by removing only the barriers in the code that prevented it from compiling.
All barriers removed
We had also frequently updated programs, where all barriers were removed and code was completely cleaned in the conversion. Then, in critical programs, especially, the conversion effort was bigger than the rewrite effort. Thirty percent of the programs were completely rewritten.
The applications are now accessed through a more efficient web-based user interface, which replaces the green screen and provides improved navigation and better overall system performance, including improved user productivity.
End-user productivity is doubled in terms of the daily operation of some business processes. Also, the overall application portfolio has been greatly simplified by this approach. The number of function points that we’re managing has decreased by 33 percent.
From a financial perspective, there are also very significant results. Hardware and software license and maintenance cost savings were about €400,000 in the first year, €2 million in the second year, and are projected to be €3.4 million this year. This represents a savings of 36 percent of the overall project.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Hewlett-Packard.
October 20th, 2009
SOA user survey defines latest ESB trends, middleware use patterns
Take the BriefingsDirect middleware/ESB survey now.
Forgive my harping on this, but I keep hearing about how powerful social media is for gathering insights from the IT communities and users. Yet I rarely see actual market research conducted via the social media milieu.
So now’s the time to fully test the process. I’m hoping that you users and specifiers of enterprise software middleware, SOA infrastructure, integration middleware, and enterprise service buses (ESBs) will take 5 minutes and fill out my BriefingsDirect survey. We’ll share the results via this blog in a few weeks.
We’re seeking to uncover the latest trends in actual usage and perceptions around these SOA technologies — both open source and commercial.
How middleware products — like ESBs — are used is not supposed to change rapidly. Enterprises typically choose and deploy integration software infrastructure slowly and deliberately, and they don’t often change course without good reason.
But the last few years have proven an exception. Middleware products and brands have shifted more rapidly than ever before. Vendors have consolidated, product lines have merged. Users have had to grapple with new and dynamic requirements.
Open source offerings have swiftly matured, and in many cases advanced capabilities beyond the commercial space. Interest in SOA is now shared with anticipation of cloud computing approaches and needs.
So how do enterprise IT leaders and planners view the middleware and SOA landscape after a period of adjustment — including the roughest global recession in more than 60 years?
This brief survey, distributed by BriefingsDirect for Interarbor Solutions, is designed to gauge the latest perceptions and patterns of use and updated requirements for middleware products and capabilities. Please take a few moments and share your preferences on enterprise middleware software. Thank you.
October 19th, 2009
Speaking of SOA: Are services nouns or verbs?
This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.
By Jason Bloomberg
ZapThink revels in stirring up controversy almost as much as we enjoy clarifying subtle concepts 
that give architects that rare “aha!” moment as they finally discern the solution to a particularly knotty design problem. Last month’s “process isomorphism” ZapFlash, therefore, gave us a particular thrill, because we received kudos from enterprise architects for streamlining the connections between Business Process Management (BPM) and Service-Oriented Architecture (SOA), while at the same time, several industry pundits demurred, disagreeing with our premise that services should correspond one-to-one with tasks or subtasks in a process.
Maybe we got it wrong, and inadvertently mislead our following of architects? Or perhaps the pundits were off base, and somehow ZapThink saw clearly a best practice that remained obscure to other experts in the field?
Upon further consideration, the true answer lies somewhere in between these extremes. Now, we’re not reconsidering the conclusions of the process isomorphism ZapFlash. Rather, further explanation and clarification is warranted.
As with any best practice, process isomorphism doesn’t apply in every situation, and not every service should correspond to a process task or subtask. That being said, there is also a good chance that some of our esteemed fellow pundits might not be opining from a truly service-oriented perspective, as many of their comments hint at an object-oriented (OO) bias that may be too limiting in the SOA context.
In fact, understanding which services the process isomorphism pattern applies to, and how other services support such services goes to the heart of how to think about services from a SOA perspective.
The object-oriented context for services
In the early days of web services, as various standards committee members tried to hash out how core standards should support the vision of SOA, the SOAP standard for message transport was an acronym for the “Simple Object Access Protocol.” The reasoning at the time was that services were interfaces to objects, and hence service operations should correspond to object methods, also known as remote procedures.
SOAP was nothing more than a simple, XML-based way of access those methods. Over time, however, people realized that taking this Remote Procedure Call (RPC) approach to service interfaces is too limiting: It leads to tightly coupled, synchronous interactions that constrain the benefits such services could offer. Instead, the industry settled on document style as being the preferred interface style, which expects requests and responses to conform to schemas that are included in the service contracts by reference, where the underlying service logic is responsible for validating interactions against the relevant schemas.
Document style interfaces provide greater loose coupling than their RPC-style cousins because many changes to a service need not adversely impact existing service consumers, and furthermore, document style interfaces facilitate asynchronous interactions where a request need not correlate immediately with a response. In fact, the W3C eventually dropped the “Simple Object Access Protocol” definition of SOAP altogether, and now SOAP is just SOAP, instead of being an abbreviation of anything.
The answer is straightforward: If a service has no operations, then what it’s supposed to do is understood from the context of the service itself.
However, document style interfaces still allow for operations, only now they’re optional rather than mandatory as is the case with RPC-style interfaces. The fact that operations are optional is a never-ending sense of confusion for students in our Licensed ZapThink Architect course, perhaps because of the object-oriented pattern of thinking many of today’s techies follow, often without realizing it.
How would you ever know what a service is supposed to do, the reasoning goes, if you don’t call an operation on that service? The answer is straightforward: if a service has no operations, then what it’s supposed to do is understood from the context of the service itself. For example, an insurance company may want a service that simply approves a pending insurance policy. If we have an approvePolicy Service, the consumer can simply request that service with the policy number of the policy it wants to approve.
Nouns vs. Verbs
The insurance policy example brings up a fundamental question. Which is the service, the insurance policy entity or the approve policy task? In other words, should services be nouns or verbs? It’s possible to design services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?
If you look at the question of whether services should be nouns or verbs from the OO perspective, then services are little more than interfaces to objects, and hence it’s best to think of services as nouns and their operations as the verbs. For example, following the OO approach, we might have an insurance policy object with several operations, including one that approves the policy, as the following pseudocode illustrates:
myPolicy = new Policy (); … successOrFailure = myPolicy.approve ();
The first statement above instantiates a particular policy, while the second one approves it, and returns either success or failure.
Now, it is certainly possible to create a Policy Service as an Entity Service that has an approve operation that works more or less like the example above, with one fundamental difference: because services are fundamentally stateless, you don’t instantiate them. Here, then, is pseudocode that represents how an Entity Service would tackle the same functionality:
request to create new policy, specifying create policy operation –> Policy Service –> response with policy number 12345
…
request to approve policy 12345, specifying approve policy operation –> Policy Service –> response with success or failure
Note that we’re representing service interactions as input and output messages that contain documents, where in this case, the input documents specify operations. In this example, there is no object in the OO sense representing policy 12345 and maintaining the state information that indicates whether or not that particular policy is approved or not.
Instead, the underlying service implementation maintains the state information. There is only the one Policy Service, and it accepts requests in the form of XML documents and returns responses, also in the form of XML documents. If a request calls the create policy operation, then the Policy Service knows to create the policy, while a request that specifies the approve policy operation follows the same pattern.
Note that the fact that the Policy Service has a document style interface gives us two advantages: First, we can make certain changes to the service like adding new operations without adversely impacting existing consumers, and second, its stateless nature enables asynchronous interactions, where instead of returning success or failure of the approve request, perhaps, the service returns a simple acknowledgment of the request (or perhaps no response at all), and then notifies the consumer at some point in the future that the policy has been approved, either through a one-way notification event or possibly as a response to a further query.
Task services as verbs
While there is a significant role for Entity Services in SOA, it is important to break free from OO-centric thinking and consider other types of services as well that serve other purposes. In fact, there is another way of offering the same functionality as the Entity Service above where the Services represent verbs rather than nouns, what we call Task Services. Here is the pseudocode for this situation:
request to create new policy –> createNewPolicy Service –> response with policy number 12345
…
request to approve policy 12345 — > approvePolicy Service –> response with success or failure
In this example, neither Task Service has any operations, but rather the functionality of each Service is understood from the context of the Service. After all, what would an approvePolicy Service do but approve policies? If you read the process isomorphism ZapFlash, the benefits of delivering capabilities as Task Services is clear. If you design each Task Service to represent tasks or subtasks in business processes, then it’s possible to build a service-oriented business application (SOBA) that is isomorphic to the process it implements.
Combining entity and task services
A casual reading of the process isomorphism ZapFlash might lead you to think we were suggesting that all services should be Task Services. However, in spite of the fact that architects with OO backgrounds often rely too heavily on Entity Services, such services do play a critical role in most SOA implementations.
Remember that in the enterprise context, services expose existing, legacy capabilities and data that are typically scattered across different applications and data stores, limiting the enterprise’s agility and leading to high integration maintenance costs, poor data quality, reduced customer value, and other ills all too familiar to anybody working within a large organization’s IT department. SOA provides best practices for addressing such issues by abstracting such legacy capabilities in order to support flexible business processes.
Both Entity and Task Services help architects connect the dots between legacy capabilities on the one hand, and flexible process requirements on the other, as the figure below illustrates:
In the figure above, the bottom row contains Entity Services, which directly abstract underlying legacy capabilities. Above the Entity Services lie the Task Services, which may actually be abstractions of individual operations belonging to underlying Entity Services. The top layer contains Process Services, which are typically compositions of Task Services. In other words, Process Services are interfaces to SOBAs, and when those SOBAs are compositions of properly designed Task Services, they will exhibit process isomorphism.
The essential question for the architect is which capabilities to abstract in which service layer. Take for example the Address Change Task Service. Changing addresses is a common example of a particularly challenging task in many large organizations, because address information is typically maintained by different applications and data stores in a haphazard, inconsistent manner. To make matters worse, there may be addresses associated with customers, policies, or other business entities.
When architecting the Customer Entity Service, the core design principle is to pull together the various instances of customer-related information and functionality across the as-is legacy environment into a single, consolidated representation. Such a Service will likely have an update address operation, and the Customer Entity Service’s logic will encapsulate whatever individual queries and API calls are necessary to properly update customers’ addresses across all relevant systems.
The Address Change Task Service, then, abstracts the Customer Entity Service’s update address operation, as well as whatever other address change operations other Entity Services might have. The Service logic behind this Task Service understands, for example, that insured properties in polices have addresses and customers have addresses, and these addresses are related in a particular way, but are by no means equivalent.
The ZapThink take
As is usually the case, architects have several options at their disposal, and knowing which option is appropriate often depends on the business problem, an example of the “right tool for the job” principle. If the business problem is process-centric, say, a need to streamline or optimize the policy issuance process, then implementing SOBAs as compositions of Task Services will facilitate process flexibility.
In other cases, the business problem is more information-centric than process-centric, for example, putting consolidated customer information on a call center rep’s screen. In such instances the architect’s focus may be on an Entity Service, because the rep is dealing with a particular customer and must be able to interact with that customer in a flexible way.
The big picture of the SOA architect’s challenge, of course, is delivering agility in the face of heterogeneity. On the one hand, the IT shop contains a patchwork of legacy resources, and on the other hand, the business requires increasingly agile processes. Understanding which capabilities belong in Entity Services and which belong in Task Services is a critical part of the best practice approach to SOA.
This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.
SOA and EA Training, Certification and Networking Events
In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
October 16th, 2009
What's on your watch list? Forrester identifies 15 key technologies for enterprise architects
Riding the right — or wrong — technology wave can help — or really, really hurt — your business. Moving at the right time can be the critical factor between the two outcomes.
Yet new technologies come down the pike at alarming speed. Deciding which will fizzle and which will sizzle — and when — can be a daunting and ongoing task. What’s an enterprise architect to do?
Forrester Research has tried to sort things out with a new report, “The Top 15 Technology Trends EA Should Watch.” And, if even limiting the selection to 15 sounds like a lot to keep your eye on, Forrester has grouped them into five major “themes,” and has ranked the technologies by their impact, newness and complexity.
Calling “impact” the most important criterion, the report says this considers whether the technology will deliver new business capabilities or allow IT to improve business performance.
“Newness” comes in second because it’s likely that enterprises will have to gear up to learn new processes and the processes themselves are prone to rapid evolution. “Complexity” places other demands on the business, requiring more time to learn operations that are more complex than others.
The five themes identified by Forrester, along with their associated technologies, are:
- Social computing in and around the enterprise
- Collaboration platforms become people-centric
- Customer community platforms integrate with business apps
- Telepresence gains widespread use
- Process-centric data and intelligence
- Business intelligence goes real time
- Master data management matures
- Data quality services become real-time
- Restructured IT services platforms
- SaaS will be ubiquitous for packaged apps
- Cloud-based platforms that become standard infrastructure and platform as a service
- Client virtualization is ubiquitous
- Agile and fit-to-purpose applications
- Mobile as the new desktop
- Apps and business processes go mobile
- Mobile networks and devices gain more power
The technologies range from real-time business intelligence (BI) with a very high impact, high newness and high complexity to data- and content-based security, which scored a medium in all three categories. I guess that keep my friend Jim Koblielus busy for some time.
Forrester limited the report to a three-year horizon for two reasons. First, it represents the planning horizon for most firms and, second, any technology that won’t have an effect in less than three years may be interesting, but it’s not actionable.
The report also says that we’re entering a new phase of technology innovation. This analysis is based on Forrester’s finding that technology change goes through two waves. The first involves innovation and growth. This features a rapid evolution of the technology and rapid uptake by businesses. The second phase is refinement and redesign, in which technologies are only incrementally improved.
I hear a lot these day about “inflection points” in the IT market. I hear folks point to the hockey stick growth effect coming for netbooks/thin clients/desktop virtualization/Windows 7. I like to add the smartphones and Android-o-hones to that category too.
And even if the cloud is a slow burn, rather than hockey stick, the importance of business processes supported by services supported by all the old and new suspects is huge. I call the ability to refine and adapt business processes as the big productivity maker of the next decade — supported by IT as services.
Perhaps the new Moore’s Law is less about systems, and more about what people do with the services those systems enable. What do you think?
Incidentally, the full report is available for download from Forrester.
BriefingsDirect contributor Carlton Vogt provided editorial assistance and research on this post.
October 15th, 2009
Oracle's Fusion Apps finally come out from behind the OpenWorld curtain
This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.
By Tony Baer
Like almost every attendee at just-concluded Oracle OpenWorld, the suspense on when Oracle would finally lift the wraps on Fusion Apps was palpable. Staying cool with minimizing our carbo
n footprint, we weren’t physically at Moscone, but instead watching the webcasts and monitoring the Twitter stream from our home office.
The level of anticipation over Fusion apps was palpable. But it was hardly suspense as it seemed that a good cross-section of Twitterati were either analysts, reference customers, consultants or other business partners who have had their NDA sneak peaks (we had ours back in June), but had to keep our lips sealed until last night.
There was also plenty of impatience for Oracle to finally get on with a message that was being drowned out by its sudden obsession with hardware. Ellison spent most of his keynote time pumping up its Exadata cache memory database storage appliance and issuing a $10 million challenge to IBM that it can’t match Oracle’s database benchmarks on Sun.
Yup, if the Sun acquisition goes trough, Oracle’s no longer strictly a software company, and although the Twiterati counted its share of big iron groupies, the predominant mood was that hardware was a distraction.
“This conference has been hardware heavy from the start. Odd for a software conference,” tweeted Forrester analyst Paul Hamerman. “90 minutes into the keynote, nothing yet on Fusion apps.”
“Larry clearly stalling with all this compression mumbo jumbo,” “Larry please hurry up and tell the world about Fusion Apps, fed up of saying YES it does exist to your skeptics,” and so on read the Twitter stream.
There was fear that Oracle would simply tease us in a manner akin to Jon Stewart’s we’ll have to leave it there dig at CNN: “I am afraid that Larry soon will tell that as time has run out he will tell about Fusion applications in next OOW.” A 20-minute rousing speech from Calif. Gov. Arnold Schwarzenegger served as a welcome relief from Ellison’s newly found affection for big iron toys.
Ellison came back after the Governator pleaded with the audience to stick around awhile and drop some change around California as the state is broke. The break gave him the chance to drift over to Oracle Enterprise Manager, which at least got the conversation off hardware.
Ellison described some evolutionary enhancements where Oracle can track your configurations trough Enterprise Manager and automatically manage patching. As we’ve noted previously, Oracle has compelling solutions for all-Oracle environments, among them being a declarative framework for developing apps and specifying what to monitor and auto-patch.
The main topic
But the spiel on Enterprise Manager provided a useful back door to the main topic, as Ellison showed how it could automate management of the next generation of Oracle apps. Ellison got the audience’s attention with the words, “We are code complete for all of this.”
Well almost everything. Oracle has completed work on all modules except manufacturing.
Ellison then gave a demo that was quite similar to one that we saw under NDA back in the summer. While ERP emerged with and was designed for client/server architectures, Fusion has emerged with a full Java EE and SOA architecture; it is built around Oracle Fusion middleware 11g and uses Oracle BPEL Process Manager to run processes as orchestrations of processes exposed from the Fusion Apps or other legacy applications. That makes the architecture of Fusion Apps clean and flexible.
But at this point, Oracle is not being any more specific about rollout other than to say it would happen sometime next year.
It uses SOA to loosely couple, rather than tightly integrate with other Fusion processes or processes exposed by existing back end applications, which should make Fusion apps more pliant and less prone to outage.
That allows workflows in Fusion to be dynamic and flexible. If an order in the supply chain is held up, the process can be dynamically changed without bringing down order fulfillment processes for orders that are working correctly. It also allows Oracle to embed business intelligence throughout the suite, so that you don’t have to leave the application to perform analytics.
For instance, in an HR process used for locating the right person for a job, you can dig up an employee’s salary history, and instead switching to a separate dashboard, you can instead retrieve and display relevant pieces of information necessary to see comparisons and make a decision.
Fusion’s SOA architecture also allows Oracle to abstract security and access control by relying on its separate, Fusion middleware-based Identity Manager product. The same goes with communications, where instant messaging systems can be pulled in (we didn’t see any integration with Wikis or other Web 2.0 social computing mechanisms, but we assume that they can be integrated as services.). It also applies to user interfaces, where you can use different rich internet clients by taking advantage of Oracle’s ADF framework in JDeveloper.
Oracle concedes the obvious: Outside of the mid-market, there is no greenfield market for ERP, and therefore, Fusion Apps are intended to supplement what you already have, not necessarily replace it.
That includes Oracle’s existing applications, for which it currently promises at least a decade of more support. But at this point, Oracle is not being any more specific about rollouts other than to say it would happen “sometime next year.”
This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.
October 13th, 2009
Engine Yard draws funding as it ushers more developers onto the Ruby services train
This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.
Developers are a mighty stubborn bunch. Unlike the rest of the enterprise IT market, where a convergence of forces have favored a nobody gets fired for buying IBM, Oracle, SAP, or Microsoft, developers have no such herding instincts. Developers do not always get with the [enterprise] program.
For evidence, recall what happened the last time that the development market faced such consolidation. In the wake of web 1.0, the formerly fragmented development market – which used to revolve around dozens of languages and frameworks – congealed down to Java vs .NET camps. That was so 2002, however, as in the interim, developers have gravitated toward choosing their own alternatives.
The result was an explosion of what former Burton Group analyst Richard Monson Haefel termed the Rebel Frameworks (that was back in 2004), and more recently in the resurgence of scripting languages. In essence, developers didn’t take the future as inevitable, and for good reason: the so-called future of development circa 2002 was built on the assumption that everyone would gravitate to enterprise-class frameworks.
Java and .NET were engineered on the assumption that the future of enterprise and Internet computing would be based on complex, multitier distributed transactional systems. It was accompanied by a growing risk-aversion: Buy only from vendors that you expect will remain viable. Not surprisingly, enterprise computing procurements narrowed to IOSM (IBM, Oracle, SAP, Microsoft).
Different dynamic
But the developer community lives to a different dynamic. In an age of open source, expertise for development frameworks and languages get dispersed; vendor viability becomes less of a concern. More importantly, developers only want to get the job done, and anyway, the tasks that they perform typically fall under the enterprise radar.
Whereas a CFO may be concerned over the approach an ERP system may employ to managing financial system or supply chain processes, they are not going to care about development languages or frameworks.
The result is that developers remain independent minded, and that independence accounts for the popularity of alternatives to enterprise development platforms, with Ruby on Rails being the latest to enter the spotlight.
In one sense, Ruby’s path to prominence parallels Java in that the language was originally invented for another purpose. But there the similarity ends as, in Ruby’s case, no corporate entity really owned it. Ruby is a simple scripting language that became a viable alternative for web developers once David Heinemeier Hansson invented the Rails framework. The good news, Rails makes it easy to use Ruby to write relatively simple web database applications. Examples of Rails’ simplicity include:
- Eliminating the need to write configuration files for mapping requests to actions
- Avoiding multi-threading issues because Rails will not pool controller (logic) instances
- Dispensing with object-relational mapping files; instead, Rails automates much of this and tends to use very simplified naming conventions.
The bad news is that there are performance limitations and difficulties in handling more complex distributed transaction applications. But the good news is that when it comes to web apps, the vast majority are quite rudimentary, thank you.
The result has propelled a wave of alternative stacks, such as LAMP (Linux-Apache web server-MySQL-and either PHP, Python, or Perl) or, more recently, Ruby on Rails. At the other end of the spectrum, the Spring Framework takes the same principle – simplification – to ease the pain of writing complex Java EE applications – but that’s not the segment addressed by PHP, MySQL, or Ruby on Rails. It reinforces the fact that, unlike the rest of the enterprise software market, developers don’t necessarily take orders from up top. Nobody told them to implement these alternative frameworks and languages.
Although hardly the only cloud provider out there that supports RoR development, Engine Yard’s business is currently on a 2x growth streak. Funding stages the company either for IPO or buy out.
The latest reminder of the strength of grassroots markets in the developer sector is Engine Yard’s securing of $19 million in C funding last week. The backing comes from some of the same players that also funded SpringSource (which was recently acquired by VMware). Some of the backing also comes from Amazon, whose Jeff Bezos owns outright 37Signals, the Chicago-based provider of project management software that employs Heinemeier Hansson. For the record, there is plenty of RoR presence in Amazon Web Services.
Engine Yard is an Infrastructure-as-a-Service (IaaS) provider that has optimized the RoR stack for runtime. Although hardly the only cloud provider out there that supports RoR development, Engine Yard’s business is currently on a 2x growth streak. Funding stages the company either for IPO or buy out.
At this point the script sounds similar to SpringSource whose new owner, VMware, is launching a development and runtime cloud that will eventually become VMware’s Java counterpart to Microsoft Azure.
It’s tempting to wonder whether a similar path will become reality for Engine Yard. The answer is that the question itself is too narrow. It is inevitable that a development and runtime cloud paired with enterprise plumbing (e.g., OS, hypervisor) will materialize for Ruby on Rails. With its $19 million funding, Engine Yard has the chance to gain critical mass mindshare in the RoR community – but don’t rule out rivals like Joyent yet.
This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.
October 1st, 2009
Private clouds: A valuable concept or buzzword bingo?
This guest post comes courtesy of Ronald Schmelzer, senior analyst at Zapthink.
Take the BriefingsDirect middleware/ESB survey now.
By Ronald Schmelzer
Every once in a while, the machinery of marketing goes haywire and starts labeling all manner of things with inappropriate terminology. The general rationale of most marketers is that if there’s a band wagon rolling along somewhere and gaining some traction in the marketplace, it’s best to jump on it while it’s rolling.
After all, much of the challenge of marketing products is getting the attention of your target customer in order to get an opportunity to pitch products or services to them. Of course, if it doesn’t work with one band wagon, as the old adage goes, try, try again. This is why we often see the same products marketed with different labels and categories applied to them. Sure, the vendors will insist that they have indeed developed some new add-on or tweaked a user interface to include the new concept front and center, but at the very core of it, the products remain fundamentally unchanged.
Now, I don’t want to sound overly pessimistic about product marketing and the state of IT research and development, since the industry couldn’t exist without innovations that are truly new and disruptive and change the very face of the market. However, this sort of innovation often comes not from the established vendors in the market (who have customer bases to grow and defend), but rather from small upstarts that have nothing to lose. It is in this context that we need to evaluate some of the marketing terminology currently coming to the fore around the cloud computing concept.
ZapThink has had many positive things to say about cloud computing, and we do believe that as a business model, technological approach, and service-oriented domain it will have significant impact on the way companies large and small procure, develop, deploy, and scale their applications. Indeed, we’re starting to see hundreds of companies that develop whole products and services without procuring a penny of internal IT hardware or software resources. This is the bonanza that is cloud computing.
Yet, we’re now starting to see the emergence of a more perplexing concept called “private clouds.” If the benefit of the cloud is primarily loosely coupled, location-independent virtualized services (implemented in a service-oriented manner, of course), and we’re doing this with the intent of reducing IT expenditures, then is there any value in a new concept called private clouds? How does the addition of this word “private” add any value to the sort of service-oriented cloud computing that we’ve been now talking about for a handful of years? Is this a valuable term, or mere marketing spin?
To attempt to gain some clarity around this issue, ZapThink reached out to a number of pundits and opinion-leaders in the space to get their thoughts and definitions on private cloud, and to no surprise, the definitions all varied significantly. Let’s explore these definitions and see what additional value (if any) they contribute to the cloud computing discussion.
Private cloud concept #1: Company-owned and operated, location-independent, virtualized (homogeneous) service infrastructure
My colleague, Jason Bloomberg, is of the opinion that a private cloud consists of infrastructure owned by a company to deploy services in a virtualized, location-independent manner. What differentiates private clouds from simply implementing clustered applications or servers, is that the cloud is not built for a specific service or application in mind.
Rather, it is an abstracted, virtualized environment that allows for deployment of a wide range of disparate services. It is important to note that in practical terms, companies will most likely not implement this vision of private clouds using a diversity of heterogeneous infrastructure. Indeed, it is in their best interests to control costs and complexity of support, training, and administration by implementing their private clouds using a single vendor stack.
So, this vision of private clouds is often a single-vendor (homogeneous) cluster of virtualized infrastructure that enables location-independent service consumption. Of course, implementing any sort of homogeneous stack reduces the need for loosely-coupled services, and thus weakens the service-oriented cloud computing value proposition as a whole for that company.
Private cloud concept #2: Virtualization plus dynamic provisioning (elasticity)
In a response to a Facebook post, Jean-Jacques Dubray comments that the above definition doesn’t go far enough. Rather, in order for the company-owned and implemented infrastructure to be considered a private cloud, it must include the concept of “elasticity.” Specifically, this means that the hardware and software resources must be provisioned in a dynamic manner, scaling up and down to meet changes in demand, thus enabling a more responsive and cost-sensitive approach to IT provisioning.
This idea of private clouds sounds a lot like the utility computing concept sold as part of IBM’s decade-old vision of on-demand computing. From this perspective, a private cloud is company-owned on-demand utility computing implemented with services instead of tightly coupled applications.
Private cloud concept #3: Governed, virtualized, location-independent services
In a response my Tweet on the subject, David Chappell comments that the private cloud is really a response to some of the security and governance issues raised by the (public) cloud. Specifically, he states that a “private cloud (equals) more control over what and how.”
Reading between the 140 character lines, I can guess that his perspective is that a private cloud is a governed cloud that enables virtualized, governed, location-independent services. For sure, there has been a lot of consternation over the fact that the most popular “public” clouds share infrastructure between customers and require that data and communications cross the company firewall.
This stresses out a lot of IT administrators and managers. So in response, these folks insist that they want all the technological benefits of cloud computing, but without the governance risk of having it reside in someone else’s infrastructure. Basically, they want the virtualization, loose coupling, and location-independent benefits of cloud computing without the economic benefits of leveraging someone else’s costs and investments. Basically, they would rather own a version of the Amazon EC2 than use it, solely for reasons of governance.
Many people are indeed concerned about those supposed governance and security draw-backs of cloud computing. However, rather than simply dismissing the economic benefits of the public clouds, why can’t we simply approach private clouds as a veneer that we place on top of the public clouds?
Couldn’t companies impose their governance and security requirements on third-party infrastructure, using company-owned governance tools and approaches to manage remote services? Couldn’t we simply demand that the public clouds provide greater governance and security control?
Basically, does the addition of the term private provide the same sort of value as it does in the context of the virtual private network (VPN)? We didn’t throw out the Internet because it was insecure and create a private Internet. So, why should we do the same with cloud computing and create private clouds?
Private cloud concept #4: Internal business model for pay on demand consumption of location-independent, virtualized resources
JP Morgenthal takes an entirely different perspective on the private cloud concept and insists that the primary value of any cloud, whether implemented privately or acquired from a public vendor, is the business model of pay-as-you-go service consumption.
From this perspective, a private cloud is an internal business model that enables organizations to consume and procure internal, virtualized, loosely coupled services using a pay on-demand model similar to a charge-back mechanism. Rather than an IT organization paying for and supporting the costs of the business users in an aggregate fashion, they can provide those resources using the same business models employed by Amazon, Google, Salesforce.com and others in their public clouds.
In order to realize this vision of private clouds, companies need a means to enable transactional service purchases, auditing of service usage, and organizational methods for enabling such inter-departmental charges. At the most fundamental level, this vision of the private cloud treats IT as a business and a service provider to the rest of the organization.
Private cloud concept #5: Marketing hype, pure and simple
TechTarget offers the most cynical view of the private cloud. In their words, a private cloud is a “marketing term for a proprietary computing architecture that provides hosted services to a limited number of people behind a firewall.”
“Marketing media that uses the words “private cloud” is designed to appeal to an organization that needs or wants more control over their data than they can get by using a third-party hosted service. …” Basically, they opine that the term has marketing value only. Where does this place IT practitioners? Reading between the lines, they encourage us to ignore the usage of the term.
More fodder for pundits
Thomas Bittman from Gartner recently posted a rather snarky blog post that says that if we don’t get private clouds, we’re basically silly people who are missing the boat. In that article, he states, “Can you find a better term? Go ahead.”
Yes, we can. “Service-oriented cloud computing” adequately defines an architectural and infrastructure approach to develop location-independent, loosely coupled services, in a manner that virtualizes and abstracts the implementation of these services. What additional value does the term “private” add to that? It’s not entirely clear, and as we can see from the discussion above, there’s no consensus.
Adding more fuel to the fire, a well-publicized video of Oracle’s Larry Ellison and follow-up audio post is now making the rounds where he (humorously or embarrassingly, depending on your perspective) pokes holes in the cloud computing concept as a whole and chastises IT marketing efforts.
Regardless of where you stand on the cloud computing discussion, the video sheds some light on Oracle’s perspective on this whole mess. While it would be hard to say if Ellison speaks for all of Oracle (although you would think so), it indicates that even vendors are starting to strain at the marketing hype that threatens to devalue billions of dollars of their own product investment over the prior decades.
The ZapThink take
The fact that there’s no single perspective on private cloud might indicate that none of the definitions really warrant separating the private cloud concept from that of cloud computing as a whole — especially the service-oriented sort of clouds that ZapThink espouses.
One reasonable perspective is that the definitions discussed above are simply differing infrastructural and organizational approaches to implementing service-oriented cloud computing. However, those approaches should not warrant a whole new term and certainly not millions more in infrastructure expenditure.
Trying to create a new concept of private clouds from any of a number of perspectives — architectural, infrastructural, organizational, governance, business model — seems to introduce more confusion than clarification. After all, shouldn’t all clouds, private or not, have many of the benefits described above? Doesn’t the concept of a private, company-owned cloud in some ways weaken the cloud value proposition? Who really benefits from this private cloud discussion — IT practitioners or vendors with products to sell?
The point of any new term should be to clarify and differentiate. If the term does neither, then it is part of the problem, not the solution. However, when vendors start pitching their warmed-over middleware stacks and now-dull enterprise service buses (ESB) as “private cloud” infrastructure stacks – ask yourself: Does this change what you are doing now, or is this the beating of the band wagon’s marketing drum?
The goal is not to buy more stuff – the goal is to provide the business increasing value from their existing IT investments. This is the purpose and goal of enterprise architecture and the reason why IT exists in the first place.
This guest post comes courtesy of Ronald Schmelzer, senior analyst at Zapthink.
Take the BriefingsDirect middleware/ESB survey now.
SOA and EA Training, Certification,
and Networking Events
In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
Dana Gardner is principal analyst of Interarbor Solutions. For disclosures on Dana's industry affiliations, click here or to view his full profile click here.
Subscribe to BriefingsDirect via Email alerts or RSS.
Link to BriefingsDirect podcast. Subscribe to the podcast Feed. Subscribe with iTunes.
SponsoredWhite Papers, Webcasts, and Downloads
- The Dell OEM Industry Solutions Group Beefs Up the ONE Unified Technology Platform Developed by MDI Security Systems Dell When engineers at MDI Security Systems design a global video surveillance ... Download Now
- Selecting the Right NAS Appliance for Your Workgroup LAN Dell Data storage is a major concern for enterprises today. Network attached ... Download Now
- A Formal Performance Tuning Methodology: Wait-based Tuning Quest Software Are you effectively testing an application's performance BEFORE it reaches ... Download Now
Essential Topics 
- Top-ranked Novell support for Red Hat at 50% less
- Get top-ranked Novell support for Red Hat when you switch
- Move to SUSE Linux Enterprise. Get 3 years of Red Hat support
- More interoperability, plus 3 years. Red Hat support, only from Novell
- Red Hat support, patches, updates with the interoperability of Novell
- Unrivaled Red Hat support now available from Novell
Recent Entries
- IBM feels cozy on sidelines as Oracle-Sun deal languishes in anti-trust purgatory
- HP offers slew of products and services to bring cost savings and better performance to virtual desktops
- Elastra beefs up automation offering for enterprise cloud computing
- BriefingsDirect analysts discuss business commerce clouds: Wave of the future or old wine in a new bottle?
- ZapThink explores the four stages of SOA governance that lead to business agility
Blogs From Our Sponsors
Most Popular Posts
- IBM feels cozy on sidelines as Oracle-Sun deal languishes in anti-trust purgatory
- HP offers slew of products and services to bring cost savings and better performance to virtual desktops
- Here's why text-based content access and management play crucial roles in real-time BI
- HP takes converged infrastructure a notch higher with new data warehouse appliance
- ZapThink explores the four stages of SOA governance that lead to business agility
- BriefingsDirect analysts discuss business commerce clouds: Wave of the future or old wine in a new bottle?
Top Rated
- Aster Data architects application logic with data for speeded-up analytics processing en masse+2 votes
- Here's why text-based content access and management play crucial roles in real-time BI+2 votes
- HP takes converged infrastructure a notch higher with new data warehouse appliance+2 votes
- Survey: Virtualization and physical infrastructures need to be managed in tandem+1 vote
- Technical, economic incentives mount around seeking alternatives to mainframe applications+1 vote
- Separating core from context brings high returns in legacy application transformation+1 vote
- Elastra beefs up automation offering for enterprise cloud computing+1 vote
- BriefingsDirect analysts discuss business commerce clouds: Wave of the future or old wine in a new bottle?+1 vote
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
- The best support in the Linux business
-
If Linux is going to power your mission-critical applications, you'd better have the best support known to business. Novell was rated the top provider of Linux technical support.
- Learn more >>
- The more you simplify, the more you save
-
When you transition from your existing Red Hat environment to SUSE Linux Enterprise from Novell, you can recognize dramatic cost savings, perhaps as much 50%
- Learn more >>
- Keep Up With The Latest In Document Management with The DocuMentor.
-
Doc delivers the scoop on today's enterprise content management, printer maintenance, and all other issues related to document management. It's the DocuMentor Blog.
- Learn more >>
- The more you simplify, the more you save
-
When you transition from your existing Red Hat environment to SUSE Linux Enterprise from Novell, you can recognize dramatic cost savings, perhaps as much 50%
- Learn more >>
Archives
Favorite Links
Favorite Links
- BriefingsDirect Podcasts
- BriefingsDirect Transcripts
- Chet Kapoor’s Edge of the Cloud
- Complex Event Processing
- Dana Gardner’s del.icio.us Tags
- Dana Gardner’s Tweets
- Dana’s FriendFeed
- Dave Linthicum’s Real World SOA Blog
- Designing the cloud
- Dion Hinchcliffe
- Download BriefingsDirect Podcast Transcripts
- James Kobielus Blog
- Joe McKendrick
- Making Sense of SOA
- Mary Jo Foley’s All About Microsoft Blog
- Sam Whitmore
- Sandy Kemsley
- Secure Observations
- Seeking Alpha Software
- Todd Biske Blog–Outside the Box
- Tony Baer’s OnStrategies Perspectives
- VOSibilities
ZDNet Blogs
- All About Microsoft
- The Apple Core
- Between the Lines
- BriefingsDirect
- Collaboration 2.0
- Dev Connection
- Digital Cameras & Camcorders
- Ed Bott's Microsoft Report
- Emerging Tech
- Enterprise Web 2.0
- Forrester Research
- Googling Google
- GreenTech Pastures
- Hardware 2.0
- Home Theater
- iGeneration
- Irregular Enterprise
- IT Project Failures
- Laptops & Desktops
- Lawgarithms
- Linux and Open Source
- Managing L'unix
- The Mobile Gadgeteer
- On Sustainability
- Rational Rants
- The Semantic Web
- Service Oriented
- Smartphones and Cell Phones
- Social Business
- Social CRM: The Conversation
- Software & Services Safari
- Software as Services
- Storage Bits
- Team Think
- Tech Broiler
- Technology and the Global Supply Chain
- Tom Foremski: IMHO
- The ToyBox
- Virtually Speaking
- The Web Life
- ZDNet Education
- ZDNet Government
- ZDNet Healthcare
- Zero Day
White Papers, Webcasts, and Downloads
- Five Steps to Determine When to Virtualize YourServers VMware Server virtualization isn't just for big companies. Entry-level ... Download Now
- Three Steps You Need to Know to Stop Data Loss Varonis Sensitive data exposed to misuse or loss... it is the stuff of nightmares ... Download Now
- Why Isn't Server Virtualization Saving Us More? A Few Small Changes May Dramatically Increase Your Efficiency VMware Companies have rapidly adopted server virtualization over the past few ... Download Now
Popular Sanity Saver Videos
