June 20th, 2008
SOA funding paradox: pay today, restructure tomorrow?
Analysts, pundits, and vendors alike have been fretting about how SOA can be made financially viable, but Burton Group’s Richard Watson has a different take on the situation: what if the funding flows, but the business isn’t quite ready for SOA?
‘Here’s the money, just build it. Now.’
Watson recently riffed on one of my previous posts on SOA funding dilemmas, pointing to paradoxes that tend to crop up in enterprises: the troubles with getting too much funding, and cost-justifying long-term projects in an environment that demands visible returns on a quarterly basis.
First, having too much funding for an SOA project seems like a good thing, but Watson points out that funding typically comes through the business units, which may be laying more on IT than it’s ready to handle.
For one thing, many business units aren’t showing any desire — at least yet — to share services with other parts of the enterprise. It takes a restructuring of financial mechanisms to make SOA tick, Watson says. “An organization’s incentives need to be shaped to promote service provision, service reuse and support for shared infrastructure. Other changes are required to follow through with this strategy including the accounting and financial flexibility to fund and charge-back shared infrastructure.”
In other words, pushing SOA for one or two projects becomes a fundamental restructuring of the business. As Watson puts it: “Aren’t you sorry now you started pulling on that thread? You just wanted to get funding for a SOA initiative and now you’re restructuring the business.”
This is a case where IT is being asked to do things well beyond the scope of its authority and capabilities. Can a team consumed with keeping servers and networks up and running on a daily basis also go out and restructure the business’s financial structure in its spare time?
The other issue is that business has very short time horizons in terms of demanding return on investment. SOA is a long-term process, extending over a period of years — quarterly progress may be difficult to show.
For these kinds of issues, Watson recommends good governance, in which funding is driven by a central budget, perhaps controlled by the CTO’s office. As he puts it:
“There is a mature IT governance process in place which means that while much of the funding demands are still for business unit driven projects they are funded from a central budget controlled by the CTO. The CTO architecture group has a unique vantage point from which to plan the evolution of IT, and identify the contribution each discrete project can make. The remaining demand comes from the CTO-governed group itself for strategic projects, including those that cannot show ROI over one, two or even five years, but are crucial to transforming IT.”
June 18th, 2008
Red Hat JBoss announces Java EE middleware from the cloud
Readers of this blogsite may know that I typically don’t talk too much about specific products. And I try not to talk too much about “inflection points,” because it seems we’ve been at one every month of every year for the past 20 years. But every now and then something comes along that makes you sit up and think, “hmmm… now this could be disruptive…”
Open source, cloud, and SOA meet
The news is an enterprise-class Java application server is now available from the cloud, via Amazon Elastic Compute Cloud (EC2). What we have, then, is open-source over the cloud for building and delivering SOA applications.
This week, Red Hat announced it is offering access to its JBoss Enterprise Application Platform as a solution within EC2. EC2 and other Amazon Web Services (such as storage) offer data center essentials on an on-demand basis, with fees based on metered usage. Red Hat has already offered Linux this way since November 2007.
What this means is developers and other users have on-demand access to open source technologies for building, deploying and hosting enterprise Java applications. Java EE or J2EE server middleware has always been complex to build and maintain. Thus, these kinds of environments have tended to be limited to larger enterprises with sizeable IT and operations staff. SOA up until now has been more for well-heeled corporations.
Of course, there has been pushback against Java EE itself in recent times, with many shops moving to more lightweight frameworks, and .NET of course. And Service Component Architecture may make Java EE less relevant. But that’s another subject for another post.
Nevertheless, any offering that takes away the maintenance headaches and deployment costs associated with app servers makes it that much easier for companies to move to SOA-enabling their applications and infrastructure. This is especially the case with the long-ignored or underserved market that is now just starting to grasp SOA.
I asked Red Hat JBoss for more details on the announcement. Aaron Darcy, director of product line management for Red Hat JBoss, responded that users now can subscribe to beta support for JBoss Enterprise Application Platform on Amazon EC2 directly from Amazon for a fixed monthly fee and a variable per-instance hour fee, and will be billed by Amazon.
With the subscription, users receive monthly access to JBoss Enterprise Application Platform (with Red Hat Enterprise Linux) on the Amazon EC2 cloud, he added.
This seems like a great deal for individual users and small-budget shops, but will enterprises bite? Darcy feels that larger enterprises may see advantages in tapping into cloud-based middleware as well. He observes that “larger enterprises are typically confined by either physical, power or cooling constraints, or just simply restricted by the time is takes to get new servers up and running in their environment; Amazon EC2 gives them another environment to quickly get their applications up and running in a more efficient way.”
Darcy said customers now have two choices for using JBoss in the Amazon cloud: “They can leverage their existing JBoss EAP deployments and extend them to the cloud with Red Hat Enterprise Linux, and/or, they can purchase pre-built software appliance images of JBoss and Linux directly through Amazon.”
The JBoss offering is a “fully supported” beta, as is Amazon EC2. There is no target date for moving out of beta at this time, Darcy said.
June 17th, 2008
Analysts: Cloud computing means new role for service registries
Ed Vazquez, reporting from the recent Gartner confab in Orlando, surfaced a discussion on the evolving role of service registries in the emerging cloud computing paradigm.
Cloud computing accelerates ’search’ aspect of registries
That is, registries and repositories have been the center of attention for the past few years as service-oriented architectures have spilled over into the mainstream. They have served as internal enterprise directories and clearinghouses for services coming online that met the criteria for snapping into the SOA infrastructure.
However, what should we do about all those services that may soon be coming out of the cloud, from outside the enterprise walls? What role will registries/repositories play?
Analysts David Cearley and David Mitchell Smith explored the new route registries and repositories may be taking, which will be more in the context of search. Namely, that “services provided in the cloud by vendors and partners are required to be discoverable,” Vazquez related.
The classic “1.0″ registry that we know and are trying to love has been company-specific, managed by enterprise IT departments. The new registry may be part of the cloud itself, managing services from multiple locations anywhere across the globe. As Vazquez put it: “Indeed, the services’ location independence, afforded by properly designed SOA and deployed enabling technologies, makes it irrelevant to service consumers where the services are hosted, along with the other internal details of their delivery.”
Ironically, this sounds awfully close to the vision for the original public UDDI registries, which were scrapped a couple of years back. But ultimately, SOA will build upon services that traverse enterprise walls, and these services need to be addressed through some type of governance (or service lifecycle management) mechanisms.
As frequently noted over the years at this blogsite, enterprises are evolving into both providers and consumers of services — and the emergence of cloud computing is greatly accelerating this trend. This was also the recurring theme at the Gartner conference, and as Ed Vazquez observed: “Leaving other implications aside for now, metadata publishing and SLA compliance are among the concerns that require a deliberate metadata management architecture.”
June 16th, 2008
Are SOA ‘centers of excellence’ luxuries or necessities?
The headline for a recent InfoQ article exclaims, “Are SOA Centers of Excellence Really Necessary?” Wow, talk about heresy to even ask this question. Sort of on the level of, “Is Education Really Necessary?”
Not to fear. The article’s author, Jean-Jacques Dubray, drawing on a recent panel discussion sponsored by the SOA Consortium, ends up reaffirming the role of CoEs (or, alternatively, SOA Competency Centers) in SOA-building. (Access to a podcast on this topic here.)
However, CoEs aren’t for everyone, and may not work everywhere. The challenge, as relayed by Bruce Henderson, is that the skills that make CoEs work — vision, political savvy, and communication — “are rare.”
The notion of “centers of excellence” or “competency centers” to better manage newer IT initiatives such as SOA is one that has been proposed by consultants and analysts for some time now. Not only does such a body help kick-start SOA efforts in the business, but it’s also a way to keep such efforts above organizational politics and fiefdoms. The SOA effort can proceed without being encumbered by individual department or management agendas.
It’s a given that large government organizations and Fortune1,000 companies with multi-million-dollar technology and implementation budgets can set aside resources to field CoEs. Plus, there’s a need for standardization of processes and best practices across diverse organizations with lots of divisions and branches. However, such efforts have been slow to evolve, and may be difficult for smaller to medium-size businesses to get in place.
I recently worked with ebizQ to develop a survey on SOA governance practices, conducted in partnership with SAP, found that nine percent of respondents had established some form of competency center/center of excellence to promote and keep SOA efforts on the right track. Only six percent of the smaller companies (less than $25 million a year in revenues) had CoEs, versus 23% of the larger companies (more than $1 billion). (A Webinar on the survey results can be viewed here.)
There are views that CoEs are even more essential for smaller companies. Mike Kavis, for one, sees CoEs as an important tool for for small and medium sized businesses that can’t afford to get bogged down in process. As he put it:
“Unlike large enterprises, we don’t have the luxury of dedicating several full time employees to enforcing processes and procedures. Instead, we must put a solid framework in place and rely on our people to enforce the necessary processes. Setting up a SOA Center of Excellence and an IT Steering committee under the watchful eye of a strong executive sponsor (CIO, Chief Architect, etc.) is one way to approach it.”
The SOA Consortium panel concluded that a CoE acts as an “accelerator,” Dubray relates. “It is not essential to have one, however if you are talking about transformational and modernization, you need one. A CoE concentrates the skills that are required to deliver a successful SOA. In many ways, it is a corollary to a PMO or an Architecture practice…. You need to make sure that all the moving parts are moving the same direction.”
June 11th, 2008
You have SOA answers; we have questions
Here’s a pop quiz to test your knowledge of the inner workings of SOA.
How acquainted are you with the origins of SOAP and XML, or the essential commands of REST? What’s the story with UDDI? What the heck is a “stateless” service?
ebizQ has created this challenging quiz to test your SOA acumen. In 10 multiple choice questions, you will find out where you fall on the SOA IQ continuum.
Score an 8 out of 10 or above, and you’ll rate a place in the “SOA Boardroom.”
June 10th, 2008
Microsoft signs onto Unified Modeling Language for SOA
Back at the end of 2007, the hot topic among panelists at the SOA BriefingsDirect podcast panel hosted by Dana Gardner was Microsoft Oriented Architecture. Why, oh why, wouldn’t Microsoft get with the program and join other vendors in supporting a common approach to modeling in SOA?
Will wonders never cease?
Forrester’s Jim Kobelius, for one, was perplexed and dismayed by Microsoft’s apparent standardless approach to model-driven architecture at the time, noting the lack of a footprint for “the actual standards that have been developed like OMG’s Unified Modeling Language (UML)… Microsoft, for some reason I still haven’t been able to divine, is also steering clear of UML in terms of their repositories.”
Well, Bill Gates and Company must have listened to the podcast, because along with delivering his fond farewell address at last week’s TechEd confab in Orlando, Gates also revealed that Microsoft’s upcoming Oslo SOA-enabling product lines would support UML.
In surfacing news of this latest development, Michael Meehan points out that support for an accepted industry standard such as UML is big news coming out of a vendor that always insists on doing things its own way. But the vision for SOA is that everyone agrees to common approaches, standards, and protocols. Plus, Microsoft’s more proprietary approach, Domain Specific Languages (DSLs), have yet to gain traction, Michael observes. As he so aptly put it: “Apparently the company has decided to end its religious differences with UML for the sake of giving Oslo mass appeal.”
Graphical, abstracted service modeling is seen as key to bringing SOA projects closer to the business, since such tools can help businesspeople better visualize what the SOA will look like, and what it will connect. Embracing UML may help propel Oslo-based products into mainstream SOA efforts, since other environments (Rational, Eclipse), employ UML.
Michael’s TechTarget colleague Jack Vaughn also provides details on Gates’ announcement pertaining to UML in Oslo.
ZDNet colleague Mary Jo Foley also describes Microsoft’s plans for Oslo in a recent post, noting how features and releases will be rolled out in stages.
Michael holds forth the possibility that Microsoft may either give Service Component Architecture a run for its money, or even (gasp) play in the same space. Will wonders never cease?
UML gives Oslo a reach it never would have had if it were based on a proprietary modeling language. The UML foundation means Oslo stands a chance of being truly universal, which is as SOA a concept as you can get. It also puts pressure on the vendors backing Service Component Architecture. Has Microsoft managed to leapfrog them in terms of offering a general purpose SOA modeling platform? Or perhaps could this lead to Microsoft embracing SCA at some level, perhaps via Apache Tuscany?
June 8th, 2008
Observations: what’s moving the SOA market these days
I just had the chance to catch up with MomentumSI’s Jeff Schneider while he was up in the Princeton, NJ, area. MomentumSI does a lot of consulting and integration work for SOA projects in organizations across the country, so Jeff’s practice is a good bellwether for what’s on the minds of SOA practitioners.
He shared some of his observations on he sees moving the SOA market these days:
- Economic concerns early in the year caused some companies to tighten their SOA projects up (tighten timeframes, or stretch out start dates), but funding has not been cut in any significant way.
- There’s been a chasm between enterprise architects who design SOA and the software and app developers charged with building SOA. The EA-appdev chasm will be problematic for SOA efforts for some time to come.
- The big SOA suites from the big vendors are starting to gain traction.
- Service Component Architecture (SCA) is poised to burst on the scene over the coming months, led by most of the large vendors. SCA will, in effect, eventually displace Java Enterprise Edition/J2EE.
- Composite applications have actually been difficult to design and build, since they depend on so many processes and logic streams criss-crossing the enterprise. Jeff sees relief coming from the mashup side of the house, and proposes a new hybrid, “Rich Composite Applications,” as the way to build systems.
- There is a lot of interest — even among large organizations — in the cloud computing, or “Platform as a Service” model, of supplying IT and SOA capabilities.
June 8th, 2008
Hi, I’m an SOA consultant, and I’m here to help
Another SOA zinger from Geek & Poke’s Oliver Widder:
June 6th, 2008
Think Liquidate: Oracle dismantling BEA’s AquaLogic business?
Whenever a vendor is swallowed by another vendor, it’s inevitable that certain product lines are dispersed or disappear altogether. That may now be the case with BEA Systems, which was acquired at the beginning of the year by Oracle for a cool $8.5 billion.
In fact, Oracle seems to be wasting no time reshuffling the BEA deck. The Register’s Gavin Clarke reports that Oracle is “merging the BEA’s AquaLogic and WebLogic professional service teams, and also plans to split the AquaLogic products between ‘Web products’ - user interaction, collaboration and the Web 2.0 suite - and AquaLogic business process management (BPM).”
[UPDATE June 6… Oracle just sent out an announcement that it will be holding a Webcast on July 1st, in which Oracle President Charles Phillips and Oracle Senior Vice President Thomas Kurian will “explore how the addition of BEA products to Oracle Fusion Middleware creates a best-in-class combination.”]
AquaLogic is BEA’s SOA offering, which included goodies such as a BPM suite, registry/repository, and enterprise service bus.
The Register also reported that Oracle made many cuts in BEA management ranks, but few in professional staff. However, as we’ve seen in many acquisition scenarios, there tends to be a flight of professionals — we’ll see how things pan out with Oracle. Reportedly, the Big O is giving AquaLogic staffers the choice of working with the Web suite or the BPM product line.
Bruce Silver just published some observations about Oracle’s approach to BPM in light of the BEA acqusition, by the way. He looked at both Oracle’s and BEA’s approaches to BPM — which differ — and thinks Oracle will pursue a dual strategy with its ARIS (OEMed from IDS Sheer) and SOA Suite combo, as well as AquaLogic BPM:
“Oracle follows the BPEL paradigm in which the process does not actually perform activities itself but instead invokes services that perform the activities, and those services are defined outside of BPM, e.g. coded in Java and exposed as services in the SOA registry/repository…. AquaLogic BPM follows the more normal BPM pattern in which activity implementations are defined and used within the BPM environment itself. If services are created in SOA and exposed in the registry/repository, ALBPM can bind to those, but it’s not the only way to do it. In a SOA-based production environment, both BPMSs get you to the same place, but it’s easier to do rapid iterative BPM development and deployment the ALBPM way.”
Bruce thinks Oracle will likely “keep both threads alive until things sort out, using ALBPM on top of Fusion as the straight BPMS offering, and the current ARIS+SOA Suite to support the apps business.”
June 5th, 2008
SOA reuse is fine, that is, if you really want the service
Geek & Poke’s Oliver Widder saw my recent post on reuse issues, and points to a conundrum that often gets lost in the argument: what if nobody really wants to use the service in the first place?
Hmmm… Be careful what you service-orient, you just may get it…
June 4th, 2008
An anthropological view of SOA rituals
Remember reading “The Body Ritual Among the Nacirema” in your college sociology class? That’s the paper that stepped back and coldly analyzed the bizarre cultural rituals among a strange tribe residing somewhere in North America. Of course, the tribe being analyzed was modern-day American (Nacerima backwards).
So, it is funny and eye-opening to read the observations of someone who wandered into the “SOA party” and make observations that put perspective on the SOA culture and the predictable rituals that have developed.
The rituals around SOA go something like this:
- “There are some things everyone seems to agree on…. The most prominent of these is ‘SOA is not a technology.’”
- “This is often followed with a stern warning about how you can’t ‘buy it,’ it doesn’t come ‘in a box.’”
- “There also seems to be consensus about SOA that it is about ‘Business-IT alignment.’”
- “There is the ubiquitous prejudice (bordering on hatred) that SOA and its practitioners seem to universally hold against the poor beleaguered ‘Silo.’ (Oh Silo, who weeps for thee?)”
- “…to finish up the things everyone seems to agree on, it seems that SOA is definitely not JBOWS.”
- “…Oh, and SOA is loosely coupled. It is definitely loosely coupled.”
The author admitted feeling confused about what SOA really was, until coming across a metaphor for SOA “that finally made it click for me in a real way”:
“SOA is technology, of course, and it is architecture, but it isn’t a style of architecture, like mud huts vs. Victorian mansions; it is a scope of architecture, like Building Design vs. Urban Planning. SOA is about turning ad hoc communities of software and process into an integrated economy composed of towns that are part of larger counties that are part of larger states, and so on. SOA is about the design and execution of the master plan, the infrastructure and government and laws that all of an organizations IT entities must follow to enable peaceful, productive commerce all around.”
This metaphor, the author said, sure beats “trying to picture what ‘driving increased strategic business agility and alignment into the enterprise’ looks like in a way that can help you build it.”
June 4th, 2008
IBM’s Zollar: SOA, Web 2.0 drive IT ‘industrialization’
Last week, I posted some countervailing views on the topic of software industrialization. Some say it represents the inevitable future of IT operations and software development; others say software needs to have elements of craft, since it’s so highly specialized.
‘Industrialized’ IT needed to handle the coming SOA and Web 2.0 loads
It can be argued that application and infrastructure design need to remain more of a specialized craft, while deployment and management can be more highly automated. One reader, CobraA1, pointed out in response to the post that “developers design software. What we do is more like creating a blueprint, which as far as I know isn’t an automated process, even in the automobile industry…. developers don’t take care of production. The tools we use are like a drafting board, not like a bunch of robots in a factory.”
On the IT-industrialization-is-inevitable side is IBM, and I was finally able to obtain a transcript of Tivoli GM Al Zollar’s speech at Pulse 2008, in which he talked about where we are on the IT industrialization continuum, and the inevitable connection to SOA.
It can be argued that SOA itself is a manifestation of IT industrialization, since the methodology promotes the mass production and mass consumption of reusable services, versus custom-crafted applications. Zollar makes the point that SOA, along with Web 2.0 methodologies, are taxing the IT operations expected to support these new approaches, and that the operations themselves need to be “industrialized.”
Along with the classic Henry Ford example, Zollar touched upon other industries that changed their dynamics and enabled mass production and consumption of their commodities — electric utilities and telecommunications. While these two sectors are pretty far along on the industrialization curve, IT industrialization has only begun:
“When viewed in the same historical perspective, best practices like ITIL, Lean Sigma, CoBIT, and others are in their infancy. Indeed, IT organizations have automated silo-ed tasks and functions, and are beginning to adopt best practices… But there is still much work to be done to get beyond silo management to industrialized operations.”
Those cursed silos are holding us back again! Of course, SOA — and now Web 2.0 approaches — are breaking down those silos, and, in the process, making it easier and more cost-effective to mass-produce software for the masses. As Zollar describes it:
“…SOA and Web 2.0 technologies are not only pushing the limits of service velocity, in terms of time to market, they are driving the need for the next generation of industrialization – across ALL operational boundaries. Business processes and services delivered on SOA allow for greater agility, and the flexibility to respond to changing business needs. They also underpin many of the telecommunications, banking, and e-commerce services we rely on every day. Web 2.0 is quickly facilitating greater collaboration and sharing of ideas, opinions and experiences between peers, across business, and between business and consumer. Together these and other new technologies will transform the way we do business.”
The challenge is that while SOA and Web 2.0 are accelerating the mass production and consumption of software, IT teams are still trying to keep up on a piecemeal, if not manual basis. This calls for deeper automation, or industrialization, of the operations behind the applications, Zollar said. “But while SOA and Web 2.0 are accelerating time to market for these new and exciting services and enabling new business models, they are also driving greater levels of abstraction and complexity for IT operations teams that must manage and assure these services – without the benefit of industrialized operations.”
June 3rd, 2008
Are vendors emphasizing the wrong approach to SOA reuse?
Reuse has been considered in many circles to be the tangible core value driver that propels SOA through the business suite. Large vendors swear by it. (Example — IBM is a big proponent of the reuse paradigm for SOA.) Write once, use many times, right?
However, not everyone agrees that service reuse is a sustainable concept. James McGovern, for one, feels the concept of reuse is “a trap at many levels,” and ultimately, an “abysmal failure.”
What actually has been happening, James says, is applications or services end up being re-implemented, not reused. As he put it in a new post:
“Redeployment of selected portions of the IT portfolio have also been enabled through the use of object-orientation and therefore reuse has somewhat succeeded on a macro scale. For the most part though, it is guaranteed that when there is a technology/business change, then the entire application has to be started from scratch again.”
The more practical level of reuse occurs “by reusing business rules,” he adds. “Reuse of process feels intuitive yet at many levels is a trap, while business rules is less understood due to its non-procedural way of approaching problems while preferring declarative thinking.”
Hmm. Is the idea, then, to facilitate consistent business rules in one place that act as the triggers for specific services across the enterprise? It would be good to get more insights (or incites!) from James on this topic.
And, why isn’t there more of an emphasis on business rules reuse, then? Analysts don’t think in these terms because there aren’t enough IT vendors paying them to do so, James says. Ouch.
Readers — give us your thoughts on reuse. Can it work, or is it doomed to failure?
Loading …June 2nd, 2008
JBOGS - Just a Bunch of Governed Services
What’s the next step up from JBOWS (Just a Bunch of Web Services)? Immediate evolution to full-functioning SOA?
Such a leap may be too idealistic, and there are a couple of levels on the way. Jeff Schneider took a good look at the JBOWS (just a Bunch of Web Services) architecture, and said a couple of additional hops are necessary to reach SOA maturity. He even provides a maturity chart to track the progression.
The next phase of evolution from JBOWS is JBOGS, or Just a Bunch of Governed Services. As Jeff describes it:
“JBoGs is the natural extension of JBoWS. Services continue to be funded in a project (and often silo manner) but are designed, built and operated according to modern governance concepts. With JBoGS, a company will most likely have some type of registry / repository solution, lifecycle governance and runtime management infrastructure and practices in place.”
Jeff also observes that while SOA can’t be bought in product form, JBOGS can, since it requires some infrastructure. He notes that several customers are already in the JBOGS stage right now.
Jeff says another hop is necessary on the maturity scale before something resembling true SOA is reached. (Actually, as you see on the chart, it’s not nirvana yet). He refers to this higher state of existence as “Patches of Planned Services,” or POPS:
“Here, we’re aligning the enterprise architecture with the Services. In essence, we’re performing urban planning for communities of services. This is the ‘planning’ view of SOA typically thought of as a top-down approach. Notice that I used the word ‘patches’; I didn’t use a term like “Enterprise-Wide Planned Services” - the fact is, no one (who keeps their job) will do this across the enterprise. We’ll cut up domains (or patches) and plan one area at a time.”
Makes a lot of sense so far. Again, note Jeff left the top tier ambiguous. Jeff says we’re not ready to worry about this yet, since most of us are working on the JBOWS-to-JBOGS transition. Anyone care to take a swipe at the what that top tier should represent, if not yet true SOA?
May 30th, 2008
How SOA and IT are faring in the ‘unrecession’
Rich Seeley, who has been tracking the relationship between the overall economy and IT/SOA in the recent turbulent months, just posted an update on how SOA has been faring through it all.
SOA will sink or swim because of SOA, not the economy
He contacted Tony Baer, Jason Bloomberg, Randy Heffner, Niel Ward-Dutton, Bradley Shimmin, and yours truly for our thoughts on what’s been happening in SOAland during this period of economic uncertainty.
The general consensus from all of us is: there has been no apparent impact or downturn in support for SOA projects and initiatives. And we also generally agreed that any rise or fall in SOA’s fortunes will happen regardless of how well or how lousy the economy is doing. But it may be in many organizations’ best interests to look into service orienting.
There’s also the question of whether the economy actually is in recession or not. Some economists and observers say we are, but others are thinking twice. I think the term “unrecession” says it all. There is pain out there, but it is being felt unevenly — and not in the IT sector at this time.
No question, that pain WAS felt in the IT sector during the harsh IT recession of 2001-2003. Tony and I agreed that SOA was born during that miserable period as a way to streamline and cut costs in the post-Y2K, post-dot-bomb era.
Tony added that SOA is now experiencing a “midlife crisis,” with a backlash against the perceived complexity of SOA methodologies. (Wow, midlife crisis already? Maybe all SOA needs is a sports car…)
Tony and I also agreed that IT budgets remain pretty tight — still decimated in some cases — from the 2001-2003 downturn, so there’s not likely to be further cuts if the order did come down from corporate. However, as has been the case for most of this decade, Tony added, “there’s scant appetite at least in North America for major architectural initiatives – IT budgets and organizations are pretty lean today.”
Nevertheless, Jason Bloomberg pointed out that cutting back on SOA projects may be counter-productive to any cost-cutting efforts. “SOA offers cost savings and agility, two essential benefits in good times and bad. What smart organizations are doing is taking a more focused approach to their SOA initiatives, driving toward key business benefits with more rapid, less expensive iterations that show value quickly.”
May 29th, 2008
Looking at SOA through ESB-colored glasses
In his latest analysis published in Application Development Trends, Steve Swoyer discusses a challenge that’s often overlooked in SOA discussions: the way members of different parts of the organization view the world. Everyone may be aboard the SOA concept, Steve says, but have different ideas and support different technology approaches to make it happen.
How ‘technology prejudice’ clouds SOA decisions
For example, Steve notes that there are transaction-oriented people and EAI people (many of whom are now ESB people), who tend to see the world in from a transaction -oriented and business process-oriented point of view. Then there are data management types, who take a bigger-picture view of data sets. Then there are the Web 2.0 people, who are typically developers who don’t have a stake in either the enterprise application integration or enterprise data management worlds.
What’s wrong with this diversity of viewpoints? Steve relates the story of a data warehouse architect who attempted to set out on an SOA project with an application architect who was a “staunch ESBer:”
The application architect… saw the project through ESB-colored glasses and — not surprisingly — devised a scheme to use an enterprise service bus (ESB) as the backbone of this company’s SOA effort. That’s hardly an unorthodox view… except for one thing: in this company’s case, an ESB-centric viewpoint complicated what could have been a fairly simple integration project. In other words… this organization could have accomplished what it wanted without going the full-blown ESB route (which required purchasing and implementing a brand-name ESB from a recently-acquired software vendor).”
The ESB-versus-data architecture point of view is but one example of “technology prejudice.” Ideally, SOA should rise above that, offering business value not connected to any particular technology approach. But that’s not the way it happens in the real world.
Steve quotes consultant Mark Madsen, who makes a living out of going in and cleaning up enterprise technology messes. The problem, Madsen said, is people go into projects with their own pre-conceived notion of what technology works. “These projects go awry because their implementers, either inside IT personnel or (more frequently) outside integrators, are enamored of particular technologies or solutions — to the detriment of more functional alternatives.”
May 28th, 2008
Edge systems need a dose of SOA, too
On the peripheries of every enterprise are the “edge” applications, databases, and systems. A repository here, an embedded system there, an open source database over there, distributed servers everywhere. Corporate wouldn’t give us the budget, so we went ahead and jury-rigged this thing together anyway — so there. These systems tend not to be mission critical, and often deployed under the radar to serve a specific pain point or purpose.
Edge applications may cost five times as much as those supported by centralized SOA
The question is, should you attempt to bring these edge systems into the SOA fold? Is it even worth the effort?
Paulo Rosado and Rodrigo Castelo, writing in the latest edition of The SOA Magazine, say yes, these edgy apps (or “shadow IT”) need to be service oriented as well. Because while edge apps may be cheaper and faster to implement, they end up costing enterprises a bundle in maintenance and overhead.
Of course, many would argue that most SOA efforts themselves sit at the periphery of the mainstream enterprise. But that’s a subject for another post.
Why even consider SOA for peripheral apps and systems? Rosado and Castelo say these siloed projects cost more than more centralized projects, and eventually mushroom into more headaches for the centralized IT department:
“Projects deemed small (typically less than three man-months) are developed locally in technologies like Excel or Access, while larger projects get added to the central IT backlog. Such a model keeps business users relatively happy and eases the pressure on an understaffed central IT department. However, this huge assortment of ‘mushroom’ applications results in ever-rising maintenance and support expenditures. Without prior planning, business units end up spending up to five times more money than initially planned for supporting and evolving their applications.“
They also observe that “ignoring shadow IT incurs the risk of hindering your SOA evolution, overlooking potential application innovations that could streamline business process and increase revenue, and increasing expenditures in the long run due to retrofitting, and also potential security and governance breaches.”
Rosado and Castelo provide four key questions that need to be asked as part of any attempt to bring edge systems into an SOA effort:
- How fast can you deploy new services in your SOA environment, and at what cost? This is an important metric to discover, since time-to-market of new services will determine how well SOA is adopted at the edges. Issues around scalability, SLAs, access, and authorization (detailed below) will also affect speed of service deployment.
- Is your SOA environment ready to deliver new services with no SLA impacts on your core systems? Perform tests on your infrastructure to see how well it scales, Rosado and Castelo advise. “Because once you provide shadow IT the requested services, you need to assure their quality of service and the SLAs of your core systems, which are now serving requests to the outside. Shadow IT systems may initially be used by only a couple of end-users but can then be rapidly adopted by an entire department. An onslaught of requests will decrease your core systems’ responsiveness, making them unusable by your shadow IT and any other systems dependent on them. In the worst case, this can overload your core systems and cause them to collapse.”
- Can you control which systems access which services? “Once you expose services to your shadow IT, you must somehow ensure that only granted systems can access them.”
- Can you transitively assure authentication and authorization once you lose control over the information? Rosado and Castelo advise adding a layer to the SOA to manage fine-grained governance issues. “More important than just controlling which systems can access which services, is controlling which entities in your organization can access and change the information that is now accessible through your edge applications.”
May 27th, 2008
What’s stopping vendors from offering SOA from the cloud?
There’s been plenty of excitement — and capital investment — in on-demand or cloud computing applications over the past year or so. (Even though there may be some peril, as discussed in my last post.) But is the SOA market itself practicing the on-demand approach?
Time for SOA vendors to offer solutions SaaS-style
Not really, says Dave Linthicum, who challenges SOA vendors to start offering their solutions on an on-demand, SaaS-style basis (emphasis Dave’s):
“What I’m proposing is that the existing SOA vendors provide the same model. In essence, they accept payment only after the product is in production and do so on a subscription-type basis, where the customer can cancel at any time. What’s nice about this model is that it lowers the risk for the technology consumer and puts the focus on providing valuable technology now and for years to come. If you miss the mark and don’t provide the value, the revenue stops. However, if you’re a fit and the technology works as advertised, then you have reoccurring revenue for years to come.”
For most technology vendors, Dave points out, this will be an “unnatural act,” since they typically “require a large up-front payment to license the software, and than back-end maintenance agreements as well.”
There are some examples of the on-demand model for SOA-enabling tools and platforms emerging. In a podcast last year, Dana Gardner, along with Anrai O’Toole, explored the possibilities of what is often referred to as “Integration as a Service.” A few months after his podcast with Dana, Anrai practiced what he preached — his company, ESB provider Cape Clear, offered up its ESB into the cloud. The company was absorbed into Workday, an online ERP provider, earlier this year.
MuleOnDemand, offered by MuleSource, is another example of ESB in the cloud. Microsoft has been experimenting with a similar approach with BizTalk Services, positioned as an “Internet Service Bus” for connecting services across the network from a platform hosted by Microsoft.
SOA tools and platforms from the cloud is certainly something that would be appealing for smaller organizations that lack the time and expertise to undertake SOA efforts, and don’t have the luxury of maintaining something akin to a SOA center of excellence.
For larger organizations, let’s turn this proposition around. SaaS/cloud computing is something that has not been widely adopted by larger organizations, because they have their own in-house expertise, and rely on large portfolios of mission-critical systems and networks to stay on top of their markets.
At this level, the SaaS/on-demand/cloud model may be an approach for selling SOA to the enterprise internally. Instead of an outside vendor being the supplier of services, the corporate IT department assumes this role. A service oriented architecture could serve as the basis of an “internal cloud” that offers services on an on-demand subscription (or chargeback) basis to various consumers across the enterprise.
May 27th, 2008
Promises, promises: the elusive user-assembled app dream
Will users finally get the chance to assemble their own applications? There’s nothing really new to this promise, promulgated by vendors, consultants, and pundits. As Oliver Widder (of Geek & Poke fame) points out, this was promised as SOA started out several years ago, and now gets promised again as mashups hit the enterprise mainstream. Maybe it will all work out this time around. If not, users will have to wait for the next paradigm shift, due in 2012.
May 27th, 2008
Cloud computing’s earthly bonds
Nick Carr, who we all know doesn’t like IT anyway, picked up on a new warning about a downside of cloud computing, reported by BBC.
There’s no such thing as a ‘cloud’ — data has to be physically stored somewhere
The issue is that cloud computing is global in nature, but relies on servers and networks based in real, physical locations, within national boundaries. And therein lies the rub, as BBC’s Bill Thompson explains:
“Behind all the rhetoric and promotional guff the ‘cloud’ is no such thing: every piece of data is stored on a physical hard drive or in solid state memory, every instruction is processed by a physical computer and every network interaction connects two locations in the real world … In the real world national borders, commercial rivalries and political imperatives all come into play, turning the cloud into a miasma as heavy with menace as the fog over the Grimpen Mire that concealed the Hound of the Baskervilles in Arthur Conan Doyle’s story.”
For example, he related, Canada “has a policy of not allowing public sector IT projects to use US-based hosting services because of concerns over data protection.” The USA Patriot Act states that the FBI and other agencies can review “content stored on any computer, even if it being hosted on behalf of another sovereign state.” The UK has similar authority laid out in its Regulation of Investigatory Powers Act.
Carr adds that France also bans government ministers from using Blackberrys “since the messages sent by the popular devices are routinely stored on servers sitting in data centers in the US and the UK.” And, of course, there’s China’s firewall.
The examples cited here reflect concerns about how and where data is handled in cloud computing, or for that matter, in any type of IT arrangement that transcends national borders. It’s unclear how this relates to applications themselves.
But this does raise the question of how much do we need to know about the services we acquire or consume from other sources. And, inevitably, it raises the specter of more meddling from legal departments in IT affairs. The beauty of both SOA and Enterprise 2.0 is companies have the ability and flexibility to subscribe to and consume services from a variety of sources from within and outside the firewall. Will consuming a service first require vetting by the legal department?
A lot of these concerns are not new, and have arisen with the growth of the Internet over the past decade. Data security and auditability is perhaps the greatest concern that arises with reliance on offsite services. Additional concerns voiced at this blogsite around cloud computing include the business viability of service providers, and the matter of competitive differentiation achievable through IT.
However, momentum is clearly moving toward more services being delivered from outside the firewall, and as the case with internal IT, this is an area that needs careful, yet enlightened, management. Even if your company is located in or around the Grimpen Mire.
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Recent Entries
- SOA funding paradox: pay today, restructure tomorrow?
- Red Hat JBoss announces Java EE middleware from the cloud
- Analysts: Cloud computing means new role for service registries
- Are SOA ‘centers of excellence’ luxuries or necessities?
- You have SOA answers; we have questions
Most Popular Posts
- Think Liquidate: Oracle dismantling BEA's AquaLogic business?
- An anthropological view of SOA rituals
- Observations: what's moving the SOA market these days
- Microsoft signs onto Unified Modeling Language for SOA
- You have SOA answers; we have questions
- Hi, I'm an SOA consultant, and I'm here to help
Top Rated
- Software industrialization: not so fast, Henry Ford+5 votes
- What's stopping vendors from offering SOA from the cloud?+4 votes
- Promises, promises: the elusive user-assembled app dream+4 votes
- An anthropological view of SOA rituals+3 votes
- Observations: what's moving the SOA market these days+2 votes
- How SOA and IT are faring in the 'unrecession'+2 votes
- IBM's Zollar: SOA, Web 2.0 drive IT 'industrialization'+2 votes
- Cloud computing's earthly bonds+2 votes
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
- Escape proprietary lock-in, join the Sun Open Storage revolution
-
Join the revolution! Open Storage combines open source software with industry standard hardware to change the way the world stores, accesses, and manages its data.
- Learn more about the world's first open storage platform >>
- Performance Results: Intel Centrino with vPro technology and Intel Core 2 Duo Processor
-
"Intel® Centrino® with vPro™ Technology and the new 45nm Intel® Core™ Duo processor delivers greater than 2x the performance over older generation Intel® Centrino® components when your system is multitasking.
- View, compare, and get smart>>
Archives
ZDNet Blogs
- All About Microsoft
- The Apple Core
- Between the Lines
- BriefingsDirect
- Collaboration 2.0
- The Core Truth
- Dev Connection
- Digital Cameras
- Ed Bott's Microsoft Report
- Emerging Tech
- Enterprise Alley
- Enterprise Anti-matter
- Enterprise Web 2.0
- Feeds
- Googling Google
- GreenTech Pastures
- Hardware 2.0
- iGeneration
- Irregular Enterprise
- IT Facts
- IT Project Failures
- John Carroll
- Laptops & Desktops
- Lawgarithms
- Linux and Open Source
- Managing L'unix
- The Mobile Gadgeteer
- On Sustainability
- Rational Rants
- The Semantic Web
- Service Oriented
- The Social Web
- Software as Services
- SOHO Networking
- Storage Bits
- Team Think
- Tom Foremski: IMHO
- The ToyBox
- The Universal Desktop
- Virtually Speaking
- ZDNet Education
- ZDNet Government
- ZDNet Healthcare
- Zero Day
- BNET Industries
- Check out BNET's newest resource for managers and executives. Need to do research on your competitors? Don't have time to read every trade pub? BNET Industries is the new source for daily news, insights, and research on 11 major industries and 9,000 public companies.
-
- The technology industry from a different angle
-
- See what's hot in the auto industry
-
- Stay on top of the energy industry
