Archive for: September, 2009
September 30th, 2009
Seven ways companies go wrong with SOA
Remember, SOA is a journey, not a quick overnight fix. It’s a transformative process that your organization will follow for the long run.
A few years back, I put together a list of where companies appeared to be steering in the wrong direction in terms of SOA implementations. The list bears repeating, because the issues still keep getting in the way of SOA success. Many companies run the risk of jumping into the approach without looking at where they are leaping. Here are the most common pitfalls that could tie an SOA installation into knots.
1) Viewing SOA as a global, enterprise-scale project involving the entire enterprise: An SOA need not be a galactic initiative that sucks up resources all across the enterprise. In fact, one of the beauties of SOA that it can start small and simple, deployed across a single business process. Definitions of SOA vary, but SOA can start with something as simple as some Web services that accomplish an end-to-end process, such as fulfilling a purchase order.
2) Looking to a single vendor to offer very complete SOA solutions: There’s no such thing as buying an SOA solution; there’s no such thing as SOA in a box, no matter what a vendor may tell you. SOA is not a product that a vendor can ship to you for installation over the weekend. Rather, SOA is a philosophy around developing your infrastructure using those vendor tools. If you have a J2EE or .NET Framework, you have a framework. An SOA is what you eventually do with those frameworks.
3) Assuming that SOA will automatically grow out of a primordial soup of Web services: Many companies think they have SOA when they actually have a JBOWS (Just a Bunch of Web Services) architecture. Somehow, there’s an assumption out there that a spaghetti architecture of Web services will somehow evolve into something resembling a full-functioning SOA. Actually, it’s possible (but not advisable) to build an SOA-enabled infrastructure with no Web services at all. An organization could have 1,000 Web services, but unless these services work in concert to address specific end-to-end business processes, that does not an SOA make. One additional point about JBOWS, however — there’s nothing wrong with being in the JBOWS stage of evolution, because that’s what it is, a stage of the evolution. But don’t expect the full-fledged agility of SOA at this stage — that’s where the disappointment has crept in.
4) Build it, and they will come: SOA is not an illuminated ballpark in the middle of a cornfield that can be seen from miles around. No one will take advantage of an SOA-enabled infrastructure if they don’t know where to find it, or even if it exists. There’s a rule that if developers have to spend more than 10 minutes to find what they are looking for (and don’t find it), they will create it themselves. An SOA will never be of value if it’s confined to one silo of the organization, and its components are not made available and shared across business unit. An SOA service built, managed, and used by one business unit will cost just as much as any other legacy application.
5) Assuming that businesspeople don’t, or won’t, understand SOA: Actually, most people on the business side can intuitively grasp the potential savings and opportunities an SOA can bring. And Enterprise 2.0 and the cloud dynamic really drives the points about service orientation home on the business side. The potential of reusing services across various business units, versus paying developers to rebuild a new service in each instance, is Management and Finance 101. The difficult part is building and managing such an infrastructure, applying IT governance, monitoring, and management to ensure that services are kept up and running, are scalable, and perform well.
6) Assuming that IT people don’t, or won’t understand the business: It’s time to put this misconception, which has been weaving its way through conferences, articles, and analyst reports for years, to rest. Indeed, SOA needs to be a multi-disciplinary, cooperative effort between IT and other departments. However, IT is part of the business, and IT professionals’ paychecks are signed by the business. Most IT departments understand that they play a vital role in moving the business forward. However, inevitably, specs and priorities will change during the life of a project, and that’s why projects fail. It’s incumbent on both IT and business users to keep each other informed; both have a financial stake in the business’s success.
7) Treating SOA as something far superior to a mere mortal “project:” SOA success is delivered one project at a time. If you have been to any number of SOA conferences, or tuned into the multitude of SOA Webcasts, you probably have heard the message over and over again that “SOA is more than just another project.” Yes, true. SOA does represent a new way of thinking, and will transform your IT, and ultimately, your business processes. However, SOA still needs to be treated as a project, with the same deliberate planning of timelines, establishment of baselines, and measurement of key performance indicators as other large IT projects. SOA requires executive buy-in, it requires resources, and it requires proof that it is paying off.
September 29th, 2009
SOA, event driven architecture will be in smart systems everywhere
In recent years, we’ve been hearing a lot about the rise of event-driven architecture (EDA), and how this will factor into SOA efforts. This combination may form the foundation of emerging “smart systems.”
CalTech’s Dr. K. Mani Chandy, one of the pioneers of EDA, and author of Event Processing: Designing IT Systems for Agile Companies, says we will be surrounded by SOA and EDA in the years to come. In a new interview with Peter Schooff, Chandy explains:
“I see a great opportunity for both [SOA and EDA] in the next, I say, 20 years starting now. …I really see them being used in all aspects of daily life. I mean management of food, water, energy, health, security and logistics… And what we call smart systems. A lot of talk about smart systems and smart system architectures are fundamentally based on principles from EDA and SOA. And the benefits of these event-driven architecture applications will be directly visible to the business, they’ll be directly visible to the customer and so I think acceptance of these applications and demand for these applications will grow virally and so I see a great future for them.”
Chandy has a formula that illustrates how and why demand for EDA will grow in enterprises in the years to come: “PC-cubed,” for push for ‘price, pervasiveness, performance” accompanied by demand from “connectedness, celerity, and complexity.” The need to process complex events will not only arise in large enterprises, but also in the consumer space as well. “We see really complex events where you’re trying to detect patterns of stock prices and relate them to commodity prices. But you also see complex events in consumer applications where you’d like to know when a given item becomes cheap with one vendor versus another,” Chandy points out.
EDA has been around in various forms since the 1970s, Chandy explained. It’s roots can be traced back to enterprise application integration and sense and response systems. “EDA appeared in the 1970s in message queuing systems and later in enterprise service buses, and this is the EAI ‘parent,’” he said. “The other ‘parent’ is sense and response. In the last decade, many companies have developed sense and respond applications in finance particularly in trading. Now however, sense and response systems are being used in every aspect of life including management of water, food, energy, security, health and so on.”
September 28th, 2009
Android as mobile SOA: consider the possibilities
“Android guy” Sam Herren points out that the applications that run or will run on Android are interoperable in a service-oriented way. “I would like to position Android’s client interface with Calendar, Contacts, and Gmail as mobile SOA,” he says.
Applications such as Gmail, Calendar, Contacts, and Google Voice “are separate and have separate UIs, but they share common data that lives on the phone and simultaneously in the Google cloud,” Herren observes. “Android was built as a mobile deliverer of Google’s main services so instead of being layers of apps above the OS they are tightly integrated.”
Hmm. Based on this line of thinking, you could look at iPhone as a mobile SOA device as well. And, as previously surfaced here at this blogsite, there’s a strong analogy that can be made between SOA and the way iTunes is structured. Or, MP3 for that matter. Along with the big honking enterprise SOAs we focus on, we’re also surrounded by lots of mini-SOAs.
September 25th, 2009
XML on the wane? Say it isn't so, Jack
Jack Vaughan has got things all abuzz with a recent post that ponders whether XML’s best days are behind it.
Is the ‘X’ in Ajax (Asynchronous JavaScript and XML) fading?
With the growing popularity of Rich Internet Applications an enterprise mashups, it’s conceivable that we may see less and less XML, Jack speculates. “Like Pick or Fortran or other once-popular languages, it is conceivable that XML’s use will at some point decline.”
For example, he quotes Yahoo Architect and JSON originator Doug Crockford, the original developer of JSON (JavaScript Object Notation), who says the protocol “was a reaction to complexity arising around XML. Such complexity did not make sense in simple Web applications.”
Many applications written in Ajax (Asynchronous JavaScript And XML) “never go near XML,” Jack adds. As he puts it: “The ‘X’ in Ajax is fading. Some would say Ajax and XML have forked. At the same time, those simple Web apps are growing in complexity.”
I don’t know if XML would ever go the way of Fortan or Pick, since these are programming languages, and XML is a meta language used in conjunction with programming languages. XML is at the foundation of many integration efforts, Web services, and SOA projects. We finally have something that’s bringing together all the world’s systems and data. I have a feeling there will be lots of XML around in the years to come. But, as Jack reminds us, nothing is invincible — not even mighty XML.
September 24th, 2009
Enterprise mashup proponents start organizing
As reported a couple of days ago, the enterprise mashup market promises to be a huge one, growing to almost $2 billion in a few years. So it’s high time people involved in this space start organizing and working around some standards everyone can agree on.
Can enterprise mashup proponents avoid the mistakes made with ESBs?
A new consortium, called the Open Mashup Alliance, is the first effort to coalesce around this growing phenomenon. The group’s stated mission is to promote “the successful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability.”
One of the founding members is ZDNet’s resident Enterprise Web 2.0 guru, Dion Hinchcliffe. Additional charter members include Adobe, Bank of America, Capgemini, HP, Intel, JackBe, Kapow Technologies, ProgrammableWeb, Synteractive, and Xignite.
One of the OMA’s first endeavors is to shepherd the budding Enterprise Mashup Markup Language (EMML) specification for submission to a standards body. EMML is an XML-based, domain-specific language that was designed to address the characteristics that make mashups easier to create and reuse.
There were a bunch of supporting quotes included with the OMA’s announcement, but I think Michael Ogrinz, principal architect at Bank of America and author of the book Mashup Patterns, said it best: “For enterprise mashups to take hold, we need to remove the ‘vendor lock-in’ concerns raised by today’s proprietary toolsets. We also need to inspire the innovative minds of the open-source community to start working in this space. By establishing an open standard for mashups, the OMA and EMML addresses both of these issues.”
Perhaps the industry learned some lessons from another development that proliferated without guiding standards — the enterprise service bus. One of the fiercest criticisms of ESBs has been the way vendors took off in all different directions with their implementations before standards could be established. Perhaps we can avoid this with enterprise mashups. But the looming market size must be a huge temptation.
September 23rd, 2009
Cisco practices what it preaches, crosses boundaries with SOA
Cisco Systems apparently is doing a great job of practicing what it preaches when it comes to doing business over the network. The network systems provider — which promotes SOA and SONA (service oriented network architecture) — recently launched a “Commerce Transformation” initiative, based on SOA principles, that enabled the company to create a solid architectural and technology foundation for both existing and future application development. And the company is getting measurable results.
Cisco more than tripled transactions to $4 billion in a year via its SOA-based partner application
The initiative netted Cisco top honors as the most compelling case study for 2009, as determined in a competition held by the SOA Consortium and CIO Magazine. Brenda Michelson, a colleague over at ebizQ and a judge for the case study competition, provides a detailed description of the Cisco Systems SOA program.
The first project, the Partner Deal Registration (PDR) application, provided outside partners secure access to “Cisco pricing concessions and programs, leveraging reusable enterprise-class business services such as corporate pricing, configuration, and partner profiles that were coupled with flexible business rules for price lists, contractual discounts, and promotions, among others.”
Part of the challenge was bringing together more than 400 diverse applications based on various acquisitions, Brenda relates. “Consequently, several core business processes such as product ordering and pricing were becoming inconsistent, monolithic, complex, and inflexible to change. A lack of comprehensive end-to-end monitoring was also a concern.”
Benefits seen as a result of the program included improved process agility, productivity, detail tracking, and growth in the number of partners, deals, and bookings. “Six months after initial project rollout, the system had more than 9,000 partner users worldwide and had processed 37,000 deals worth $1.2 billion. Nearly a year later in June 2009, there were close to 20,000 partner users, and 56,000 deals worth $3.92 billion net had been processed.”
Cisco had a very comprehensive governance structure for its SOA, led by cross-functional councils comprising business and IT leaders were tasked with the planning and execution of an integrated capabilities roadmap, Brenda relates. Once the roadmap was finalized, an SOA project team consisting of an enterprise architecture team, business architects and IT architects evaluated the use of SOA. The EA team, which also acted as an SOA center of excellence, built a framework for the identification, creation, reuse, governance and monitoring of services and composite applications.
Brenda outlined some of the lessons learned. Some are well-accepted operating procedures across the industry, such as SOA governance, being about the business versus technology, and employing both a top-down and bottom-up approach becoming essential. Interestingly, one of the lessons is that business process management (BPM) needs to be part of the SOA equation. Also, the Cisco folks point out, “when you are a large company, most of the benefits will come from volume, so target simple things (services) with high volume.”
September 22nd, 2009
Services or subtasks? SOA and BPM may mean the same thing
We’ve been debating on these pages whether SOA and business process management go together, or if they’re actually two very different disciplines.
Jason Bloomberg recently provided his take on the SOA-BPM discussion, saying that SOA and BPM are structurally the same. They may, in fact, be an example of “process isomorphism.”
Jason is kind enough to provide a definition of isomorphism (”a mathematical concept that expresses a relationship between two concepts that are structurally identical but may differ in their respective implementations”). In an SOA context, process isomorphism means, hypothetically, “if you were to model a business process, and as a separate exercise, model the composition of services that implements that process, where those two models have the same structure, then they would be isomorphic.”
Looking at SOA-BPM this way, then helps to establish a common language between business and IT, Jason points out:
“The business folks can be talking about processes, and the IT folks can be talking about SOBAs, and at a certain level, they’re talking about the same thing… If process specialists want to think of Business Services as process subtasks, then they can go right ahead. Similarly, if technical implementers prefer to think of business processes as being compositions of Services, that’s fine too. And best of all, when the BPM team draws the process specification on one white board and the SOA team draws the composition specification on another, the two diagrams will look exactly alike. If that’s not business/IT alignment, then what is?”
Jason has hit upon something here, in that the perceived “rift” between SOA and BPM is more a product of semantics than actually structural differences between the two disciplines. SOA provides a collection of services that can be mapped to business processes as required.
September 22nd, 2009
Enterprise mashup market to increase tenfold over next five years
A new report from Business Insights predicts that the enterprise mashup market, worth around $161 million in 2008, will expand more than tenfold to $1.74 billion by 2013.
About 33% of companies now use enterprise mashups, Business Insights says.
The catalyst for the enterprise mashup market will be SOA — Business Insights puts the SOA platform market at about $1.4 billion in 2008, which will double in size, to about $2.77 billion by 2014.
It’s interesting that the enterprise mashup market, which currently is about 11% the size of the overall SOA platform market, will soon be 63% the size, or getting close to comparable. This is huge for the front-end part of the equation, if these numbers pan out. But does it make sense?
September 21st, 2009
Cloud offers SOA apps a 'venue to stretch their legs'
“Cloud computing is already beginning to unleash the potential of SOA and much more is on the way.”
Cloud is the target platform SOA has been lacking until now
That’s the view of Gray Hall, a veteran of the IT hosting industry, in a recent post on the growing role of SOA in cloud formations. Gray states that SOA is an architectural pattern and cloud is a target platform for that pattern. The significance of cloud, he adds, is that SOA has languished since its inception, and the reason is because it has lacked a “target platform.” As he puts it:
“[It] is correct to call SOA an architectural pattern. [It] is correct to call cloud computing a ‘target platform.’ But the real news in this story is that a target platform is exactly what SOA has been lacking all these years. All applications must run somewhere; applications need infrastructure. SOA is an application architecture; cloud computing is an infrastructure architecture. It’s that simple. This marriage is long overdue.”
Gray says that cloud processing (dynamic allocation of CPU resources) and cloud storage (Web services API access to storage resources) infrastructure “is the most natural target platform for SOA apps because cloud infrastructure is designed to scale in the way implied by the SOA approach to application architecture.”
Cloud infrastructure services such as Amazon Web Services and Rackspace have made SOA real to many companies, he says. “Until recently, where could a SOA app find a venue to stretch its legs?”
Gray has hit upon something here. SOA’s value is not seen within services built for a single silo, or even those shared between two or more silos. SOA begins to pay off as the result of a network effect — services built and consumed across a growing Web of providers and consumers. Cloud-based services are broadening organizations’ vistas as to when and where they can access services.
(Thanks to reader csarkar for the pointer to Gray’s post.)
September 21st, 2009
Twenty percent of SOA value from service reuse; where's the other 80%?
Is service reuse a worthy part of the SOA value equation? This is a question that has been endlessly debated in recent years.
Mashups may hold the key to long-term SOA value
For example, last month, we quoted Forbes’ Dan Woods, who argued that companies are focusing on building SOA-based services that will be available for reuse as soon as they are tested and released to the registry/repository. Perhaps, he says, we should worry less about reusability at the beginning phase of service development.
Or, even if reuse does deliver ROI, it may only have a limited reach. Marc Rix recently weighed in on the topic, suggesting out that “basing SOA on reuse only modernizes 20% of IT and, thus, does not yield agility.” The other 80% of the equation, he says, is based on deployment of data services.
He arrived at the 20% figure by calculating the fact that reusable services tend to be the most popular or mainstream services, and “tend to orbit around relatively static business data (employees, customers, vendors, suppliers, etc.).” Building and deploying these services means relatively immediate reuse, and therefore, ROI. However, there’s little ROI beyond the immediate rush, he says.
For SOA value, Marc says, look to the ” Long Tail of IT” — data taken out of core enterprise systems and manipulated by business users, in applications such as business intelligence and analytics. “This is where business is really conducted and this is where SOA is really needed,” he says.
Why I hear Marc saying is the real meat of SOA will be seen in more dynamic, user-created (or at least user specified) composite apps. Enterprise mashups come to mind in this context. In these situations, end users can create their own interfaces as business requirements demand. They can be quickly built and used. However, what is needed is a way to make this possible within a governed framework. With SOA governance and best practices applied on this end at the architectural level, organizations have assurance that these enterprise mashups are subject to the same security and vetting as core SOA services.
September 18th, 2009
Is cloud computing possible without SOA?
Is cloud computing possible without SOA?
Yes, but don’t expect things to move very smoothly.
Is SOA possible without cloud computing?
Of course. But don’t expect any impetus toward the loose coupling model you’re trying to promote.
I just listened to a podcast with Mike Kavis, CTO of M-Dot, who sat down with my colleague at ebizQ, Peter Schooff, to talk about SOA and the cloud and the advantages and difficulties enterprises face moving from SOA to the cloud.
Practicing SOA gives many companies a leg up when they start looking at cloud formations, Mike observes. First, he says, there’s the loosely coupled aspect of SOA — very important. “Companies who aren’t practicing service oriented architecture will be tightly coupled to their databases, will be tightly coupled to their infrastructure. So it’s very hard for them to move, or shift, or change things around,” he says. “Whereas companies with a service oriented architecture can look at their entire offering and say, ‘hey, these pieces make sense to move the cloud, these other pieces don’t,’ and they can make those moves. Without a service oriented architecture, it almost becomes an all or nothing proposition and that’s not a recipe for success.”
Mike establishes, then, that SOA is a big enabler for cloud computing. But at the same time, cloud computing is a big enabler for SOA. As Mike put it in the interview: “We all know that SOA has had its troubles catching on, and I think the movement to the cloud is one of the best things that could happen to SOA. Because what you’ll find is its very hard to move to the cloud when you’re tightly coupled to your architecture. And then I also see a lot more requirements for businesses to integrate with partners, to leverage mashups, to do those types of things, connect into other Software-as-a-Service providers.”
Mike did a great job of exploring the technical justification for SOA and cloud working together. Let me add there’s an enormous business justification for the SOA-cloud alliance as well. For years, IT has been fighting the tides trying to get business to understand what SOA is about, why it should be funded, and what the results will be. But business quickly gets cloud computing. The best way to sell SOA to the business is as an internal cloud program. Cloud finally makes SOA tangible to the business.
September 16th, 2009
First there was WS-*, now we have REST-*
Should we call it “REST-star” or “REST-splat”?
Paul Krill reports that Red Hat has launched a community-based standards set it is calling REST-*, which could serve as a counterpoint to the WS-* specifications for Web services. Red Hat says it hopes to work with major vendors such as IBM and Microsoft, “to define standards or recommendations for REST-based system integration.”
Mark Little, CTO of JBoss/Red Hat, announced the new initiative at the recent JBoss World conference in Chicago, noting that the WS-* series of Web services have become complex. “Maybe REST is a better way of doing certainly Internet-scale integration, but one of the problems of REST is it lacks clear guidelines,” for enterprise capabilities, such as security, transactions, and high availability.”
Red Hat even now has a home page for the REST-* effort, which outlines the vision, specifications, and community for the standards set.
Red Hatter Bill Burke makes the case for REST-* thusly:
“While REST has gained huge momentum in the SOA community, there hasn’t been a lot of standardization of traditional middleware services. The REST-* community aims to introduce new REST-based standards for these traditional services where none exist and provide well-defined guidelines where protocols do exist.”
There are two efforts now underway as part of the REST-* set:
REST-* Transactions: A specification that attempts to define a RESTful interface for transactions. “It describes the interaction between coordinator services and transaction participants as well as how transactions can propagate in distributed applications. It defines both a 2-Phase-Commit model as well as a Forward-Compensation protocol.”
REST-* Messaging: Messaging encompases publish and subscribe and point-to-point protocols. This specification defines a RESTful interface for queues (p2p) and topics (pub/sub).
Not everyone is welcoming the new initiative with open arms. Anne Thomas Manes, for one, says she’s “got a bad feeling about this.” She points out that REST-* may stray from REST principles, and “you won’t attain the desirable RESTful characteristics (scalability, serendipity, network effects, etc) that REST is supposed to enable.”
“A more useful effort would be one that defines RESTful patterns that support and enable mission-critical capabilities like reliable delivery, transactional integrity, and the like. But please, let’s not reinvent CORBA on REST. Here’s hoping the whole REST-* thing just dies out.”
Sure, mistakes were made with SOAP and WS-*, and Burke admits that “blind idealism,” combined with Red Hat’s experience with communities, will guide this latest effort past obstacles, complexities, and pitfalls. Red Hat is “jumpstarting and founding the standards body itself,” and is “battle tested in specifications efforts at the JCP and other bodies.” Burke adds that “we’ve often been frustrated by the closed and inflexible attributes of these organizations. We feel our open source roots and ideals make us an excellent candidate to drive and host standardization efforts.”
September 15th, 2009
ESBs are patterns, not products
Thomas Rischbeck, a contributor to Thomas Erl’s SOA Design Patterns, wants to clear the air on some of the confusion and controversy that has been associated with enterprise service buses (ESBs).
From day one, ESBs have suffered from lack of standards
That is, he writes in a new article, “The essence of an ESB can be much more easily grasped by talking about the ESB as a pattern: the pattern of applying an intermediate proxy to service communication. The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants.”
The confusion with ESBs date back to their very start, when vendors took the lead with pushing these products out to market. But they rushed things because they were under the gun, Thomas says:
“Faced with market domination by IBM, [message-oriented middleware vendors were the first to jumpstart the ESB concept with the aim of developing a unique selling proposition. They added Web service and EAI capabilities on top of existing message broker capabilities, and with analyst support coined the term ESB. ESB was positioned as a low-cost alternative to EAI and panacea for all integration needs – tell-tale signs of hype. Unfortunately, the standards community was too late to get on the bandwagon. In the absence of standards guidance and the lack of a clear definition, each vendor interpreted ESB to its advantage. As a result, comparing ESBs is like comparing apples and oranges. No two products are compatible today with severe consequences (in terms of vendor lock-in) for end users.”
As a result of all this vendor confusion and FUD-creation, ESBs mean a lot of different things to different people. Instead of thinking of ESBs in terms of what vendors say they are, Thomas urges thinking of ESBs as a pattern — as he puts it, “the pattern of applying an intermediate proxy to service communication.”
He provides a more detailed definition for the ESB pattern:
“The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants. …The ESB is a compound pattern that pulls together many enablement and enforcement capabilities that come in handy to the SOA practitioner. Reliable Messaging, Message Manipulation, Data Format and Data Model Transformation as well as Protocol Bridging are just some sub-patterns examples under the ESB umbrella. These are all enablement aspects where the ESB allows communication between endpoints not possible otherwise.”
There are two major alternatives to ESBs, Thomas adds — either application servers everywhere or nothing at all. While doable, this makes efforts to support delivery of services more complicated than they are, he says. Of course, there are many SOA proponents that say ESBs are essentially useless appendages that do more harm than good in the long run. Perhaps elevating the discussion to more vendor-neutral territory will help clarify what, if any, roles ESBs could play in tomorrow’s SOAs.
September 14th, 2009
Create, cut, create, cut: How to be a successful CIO in 18 easy steps
Being a chief information officer sounds glamorous, but is not a cake job by any stretch. CIOs are at the epicenter of the crossroads, cross currents, and crosswinds of all changes and challenges sweeping today’s business. You have to be an insightful visionary, able pragmatist, savvy value creator, and relentless cost cutter all at the same time. And be thanked and cursed at the same time.
For anyone aspiring for the CIO’s job — or already in the hotseat — IBM recently released a new global study of more than 2,500 CIOs that points to the thinking of what it takes to be successful and of value to the business.
The study looked at the activities and priorities of CIOs “high-growth” versus “low-growth” organizations, as defined by 2004–2007 profit before tax (PBT) growth for their organizations. Here are some interesting contrasts — and it can be assumed that these priorities shaped the overall businesses’ success, versus the other way around (low-growth culture depressing more proactive CIO activity).
- To innovate, 64% of high-growth CIOs actively integrate business and IT across the organization, versus 33% of low-growth CIOs.
- To pursue corporate vision, 28% of high-growth CIOs spend the greatest allocation of time and budget on new technology and business initiatives, versus 15% of low-growth CIOs. (Note how this is a relatively small minority of CIOs, even in the high-growth case.)
- In staying in maintenance mode, 40% of low-growth CIOs spend most of their time in core technology services, versus 23% of high-growth CIOs.
- To promote intra-IT collaboration, 53% of high-growth CIOs actively use collaboration and partnering technology within the IT organization, versus 33% of low-growth CIOs.
- To promote enterprise-wide collaboration, 41% of high-growth CIOs used such technology for the entire organization, versus 22% of low-growth CIOs.
- To advance business intelligence, 58% of high-growth CIOs proactively craft data into actionable information, versus 36% of low-growth CIOs.
- To stimulate customer collaboration in the next five years, 87% of high-growth CIOs expect to seek customers’ active input and interaction, compared to 70% of low-growth CIOs. (Even the low-growthers are aboard with this one.)
- To achieve enterprise standardization within five years, 61% of high-growth CIOs expect to implement completely standardized, low-cost business processes, versus 50% of low-growth CIOs. (Low-growthers seem to be aboard here as well.)
The IBM study also finds that leveraging analytics to gain a competitive advantage and improve business decision-making is now their top priority. More than four out of five (83 percent) respondents identified business intelligence and analytics – the ability to see patterns in vast amounts of data and extract actionable insights – as the way they will enhance their organizations’ competitiveness.
In addition, the IBM study also confirms that CIOs are necessarily relentless about scrutinizing budgets and processes to trim the fat. Across the entire sample, CIOs spend about 14 percent of their time removing costs from the technology environment. The report puts it this way:
To control costs, CIOs commonly view a central technology organization as the future of their function. Centralized infrastructures and processes enable shared services optimization that, in turn, provides economies of scale. Three-fourths of all CIOs—including those in both high-PBT growth and low-PBT growth organizations—anticipate having a strongly centralized infrastructure in five years.
Based on the collective wisdom IBM drew from these 2,500 CIOs, the report provides 18 key actions that can have the greatest impact on an organization’s success. (And perhaps put more in the “high-PBT growth” column next time.)
1) Push business and technology integration
2) Champion innovation
3) Extend CIO influence
4) Enable the corporate vision
5) Make working together easy
6) Concentrate on core competencies
7) Make data “sing”
8) Reach customers in new ways
9) Enhance integration and transparency
10) Standardize to economize
11) Centralize the infrastructure
12) Keep cost reduction a top priority
13) Know the business
14) Get involved with business peers in non-IT projects
15) Present and measure IT in business terms
16) Cultivate truly extraordinary IT talent
17) Lead the IT forces
18) Enhance the data
September 11th, 2009
Forrester's Randy Heffner: only one percent turned off by SOA so far
The problem with service oriented architecture is that people have been thinking about it too narrowly. Randy Heffner, VP and analyst with Forrester Research, says all too often, SOA has tended to be pigeonholed “as a technology, the next thing in line after objects, and components; and all about reuse and just about connecting between applications on the wire.
View SOA from a business design, not technology perspective
“These are all very small ways to view SOA,” he feels. “What’s much more important is to view it from a design perspective.”
I recently had the opportunity to sit down with Randy in a podcast (MP3 link here) hosted over at ebizQ site. Among other things, Randy talked about a report Forrester issued last spring in the wake of Anne Thomas Manes’ “SOA is Dead” proclamation — titled, appropriately enough, “SOA is Far From Dead, But It Should Be Buried.”
What struck me was the fact that once an organization gets going with SOA, it will tend to stick with it for the long haul. In fact, as Forrester’s statistics bear out, only a minute fraction will give up and walk away from SOA altogether. “There’s a group of folks that struggle, but most importantly, there’s only about one percent of SOA users who say, it’s provided little or no benefit and we’re cutting back,” Randy says.
In fact, Forrester’s study uncovered deep and wide support for SOA, Randy says. “The data shows that SOA is very much alive and well and very much adding value,” he explains. “Not perfectly in the sense that there are still folks that struggle, because SOA is not an easy thing. But I think a lot of the struggling with SOA comes from …is some of the misguided ways that people view SOA.” As noted above, the misguided thinking is too-narrow thinking about what SOA can accomplish.
“By the end of this year, 75% of the global 2000, that’s folks with 20,000 or more employees, say that they’ll be using SOA,” Randy continues. “When we asked, ‘Are you satisfied?’ roughly 25% says that SOA has provided most or all of the benefits that they expected. There’s another 30 to 40% that said, ‘It’s provided less than we expected, but still enough benefit that we’re expanding our use of SOA.’”
What do the 25% moving full force into SOA have in common? “They’re treating SOA as a business-design concept,” Randy says. “That sets a whole different perspective on how you view the kinds of services that you’re building, the methods that you put around it.”
An element of the business-design view of SOA that doesn’t get enough attention, Randy feels, is service portfolio management, which is an important piece of governance. “A lot of folks say ‘SOA is all about a service library, just let projects create what services they need to, and drop them in a library, and then people can search, discover something that’s there that they might be able to use.’ Well, that’s a very haphazard kind of way to go about your business.”
Instead, approaching SOA through service portfolio management emphasizes services created to address business capabilities. “You know what business you’re in. You should be creating a coherent portfolio of business capabilities that are embodied in your SOA services. And, hence, service portfolio management is a much stronger approach to building a collection of services than a service library approach.”
Listen to or download the 11:54 podcast below:
Check out the full transcript of the podcast interview.
September 8th, 2009
Advice: avoid SOA-BPM entanglements
Does it make sense to fuse SOA to business process management (BPM)? Many see the SOA-BPM alliance as an inevitable convergence — a topic we’ve riffed on repeatedly here at this blogsite.
Should SOA be viewed as ‘the nail for BPM’s hammer’?
So, the SOA-BPM alliance is a great thing, right? Actually, at least one informed observer questions whether SOA and BPM were really meant to be together at all. JP Morgenthal cautions that “SOA and BPM have very different goals. SOA is about application rationalization via a service metaphor, and BPM is about business process analysis and optimization.” They are not — repeat, are not — related, JP says.
A SOA-BPM union, forced or otherwise, may even create some big problems, he adds:
“This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words ‘boiling the ocean’ comes to mind.”
Plus, attempting to fuse SOA and BPM into one mega-effort is biting off more than most organizations can chew, he warns. SOA practitioners may see the mapping business processes into technology frameworks as the be-all and end-all. However, the BPMers are usually focused on other things, such as getting business units that may reside in separate continents on board with a redesign process. This is a bigger deal “than not having a Web service available to invoke,” he says. As JP puts it, “SOA should not be viewed as the nail for BPM’s hammer.”
JP’s view runs contrary to what many other analysts/observers seem to have been saying in recent years, that while clearly still distinct and separate, SOA and BPM are coming together, and the lines between the two disciplines are blurring. JP argues that SOA and BPM should not be one single effort, which, from a digestible project management perspective, makes sense. And BPM can currently exist without SOA. However, there is a lot of work taking place on the SOA side in terms of architecture, which lays out the blueprint for the most effective deployment of technology to support business processes. Business leaders don’t care if an initiative is called “SOA,” “BPM,” or “EA,” or “DOA.” They want an initiative that achieves faster time to market, streamlines an outmoded process, or improves front office productivity.
September 8th, 2009
Cloud may complicate SOA load balancing act
One of the major selling points of SOA and cloud computing is that service consumers don’t have to worry about the platform and hardware that the service is hosted on, be it somewhere else within the enterprise or maintained by an outside third party.
SOA’s greatest risk? Too much success, catching planners unprepared
Providers of services (and users), however, need to assure the availability of the service, and how much stress the underlying infrastructure can take as the service is repeatedly accessed. Lori MacVittie just posted a detailed analysis of the load balancing challenge associated with SOA-based deployments.
Lori cites a post by Stephan Koser, who provides a vivid scenario of what can go wrong with unbalanced SOA.
To function effectively, Lori observes, any load-balancing algorithm put into to place to assure availability and scalability of the service-delivery network be able to take into consideration the current load being handled by the particular server handling the request:
“This requires that the load balancer, the application delivery controller, be aware of the application, its environment, as collaboration well as the network and the user. It must be able to make a decision, in real-time, about where to direct any given request based on all the variables available. That includes CPU resources, what the request is, and even who the user/application is.”
However, when the cloud paradigm is introduced, this ability to see and monitor the systems providing services is, well, clouded over. If anything, Lori warns, cloud computing leads to poor visibility and renders load-balancing strategies useless. “The belief that the infrastructure should be ‘hidden’ from the user (that’s you) means that configuration options – like the load balancing algorithm – aren’t available to you as a user/deployer of cloud-based applications. Even though load balancing is going to be used to scale your application, you have no clue or control over how that’s going to occur.”
Lori very aptly points out that despite all the emphasis on virtualization, “applications are not islands,” and the ability to deliver and manage applications ” requires collaboration between a growing number of components in the data center.” Load balancing is a good start.
There’s plenty of talk about SOA failure, but, ironically, the greatest risk may come from too much SOA success. Organizations deploy shareable services, only to have them pounded into the ground by a growing number of requesting applications. Here’s a case where SOA costs may be driven up by the need to quickly put in or provision additional hardware. Cloud adds a new dimension to the challenge.
September 4th, 2009
Enterprise architecture pitfalls: the obvious, and beyond the obvious
Brenda Michelson’s latest blog post over at ebizQ employs a very 2.0-ish approach to gathering management advice. Brenda, a thought-leader in enterprise architecture, looked at Gartner’s latest list of the Top 10 EA Pitfalls, which included these points:
- Selecting the wrong lead architect to manage the process
- Not engaging businesspeople
- Not measuring and communicating the impact
- Not establishing effective EA governance early
- Not spending enough time on communications
Ho-hum.. You get the picture. Gartner’s suggestions are blindingly obvious. Brenda decided such a list needs a little more pizazz and real-world perspective. So she hashtagged (#eapitfall) a query out to her Twitter followers: Show us some “Real EA pitfalls.”
A couple of good ones that surfaced included “Example EA Pitfall: Running behind a project team waving a red flag” (courtesy of @Cybersal) or EAs turning into “standards cops” (courtesy of @gleganza).
Here are a few more from Brenda’s crowdsourced list of EA Pitfalls (all stated within 140 characters, of course):
“Most developers have no clue what project plans even say.Why bother to read them. 90% done, 2 years remaining on 6m project” (@mcgoverntheory) “Example EA pitfall - developers persuade stakeholders that EA guidelines are unnecessary redtape” (@richardveryard) “Example EA pitfall - corporate acquisition of enterprise application package preempts EA activity” (@richardveryard) “Add to EA pitfalls: Start/Shutdown Pattern: as in: ‘we’re on our 6th attempt to create #EA in last decade’” (@aleksb6) “EA Code Trap: “Our EA will build the shared/common applications/frameworks” <- not EA, it’s EAppDev” (@aleksb6) “Not applying design mind to study enterprise behavior and only creating static un-integrated artifacts.” (@sboray) “Thinking one-size-fits-all is the ideal for all scenarios (Jeanne Ross’ ‘Unification’ operating model)-makes EAs standards cops” (@gleganza) “EA Pitfall - EA is TOGAF or Zachman or another method/framework. It is about delivering real business value” (@malcolmlowe) “EA Pitfall - EA is 80% architecture 20% communication/buy-in #eapitfall. It is more like 20% architecture 80% communication/buy-in” (@malcomlowe)
September 3rd, 2009
Enough of RESTless SOA? Speak now or forever hold your peace
Speak now or forever hold your peace…
Has anyone ever actually heard someone disrupt a wedding ceremony by voicing an objection to the proposed union?
Has anyone ever heard someone object to an SOA plan because its based on SOAP, and not enough REST?
In an interesting new post, Justin Cormack says not enough people speak up when corporate decisions are made to adopt of SOAP-base Web services as the foundation of SOA, before the deal is sealed and things really start to get messy:
“I went to a meeting a while back with a company starting to move to a Web service based, internal API based architecture, and there was a minute where the CTO said (more or less) “does anyone know of any let or hindrance to this being a SOAP API?”. Like those moments at weddings, no one spoke out. But I do object. SOAP is not the backbone of a happy architecture, but we do not have the strength to say no right now.”
Justin says this is the time for enterprises to move from SOAP to REST, and transition their service oriented architecture (SOA) to a resource oriented architecture (ROA).
Not a bad nomenclature — and he makes his case for a RESTful ROA:
- Web developers favor REST. “It is more productive. It does not involve programs to generate huge chunks of useless code. It involves hypertext, not opaque documents that are mappings of database schemas.”
- REST is less expensive, as it requires fewer application development resources.
Look at modeling systems as resources, Justin continues. “Resources are much easier to work with than services, as they share uniform semantics, and they are addressable, two keys to making application design simple.” A CRM system is an example of something that needs to be modeled as resources, he says. “You need API calls that can find products a customer has bought, support tickets, all the core data that you would need to build customer service portals, internal support applications.”
REST enables a resource oriented architecture based on HATEOS or Hypertext as the Engine of Application State. HATEOS “involves is moving the vague and very expensive field of business logic from code (often code that is not even owned or understood by the enterprise, as it has been embodied into code written into systems from suppliers) into hypertext documents,” Justin explains.
Thanks to Dilip Krishnan for pointing to this post.
September 2nd, 2009
Enterprise architecture is for entrepreneurs, too
Mike Kavis asks an intriguing question: “Is enterprise architecture only for big companies?”
Small companies can’t afford to throw money away on the wrong systems
One’s first thought would be yes — it would seem that a larger organization would have a greater need for EA, since there are likely to be many systems, applications, and user groups to contend with, all under one roof. A small company, on the other hand, may be more homogeneous, with only one ERP system, one type of database, one platform, and so on. Plus, a large organization has lots of time and resources — including human resources — that can be devoted to EA planning and governance activities.
EA may be even more critical to small and medium-size companies than their larger counterparts. But there is a misconception that only big companies need EA. Mike reports that he is part of a startup with fewer than 20 employees, and yes, they are talking EA. He says Brenda Michelsen captured the misconceptions about EA perfectly in a within-140-character tweet: “Many equate EA w/jumbo frameworks & rigid governance, rather than set of values & practices for capability delivery.”
So, forget the heavy-handed frameworks, and look at what EA is really about:
“Enterprise Architecture is a complete expression of the enterprise; a master plan which ‘acts as a collaboration force’ between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks (source: IFEAD – Institute for Enterprise Architecture Developments)”
There’s nothing in this definition that specifies large organizations. If anything, smaller companies may need a master plan to guide ongoing technology projects more than a large organization that can afford to waste money on shelfware or underutilized systems.
Mike observes that EA is effective at helping a small, entrepreneurial organization meet goals that may include business architecture, business roadmaps, and portfolio management that prioritizes what gets worked on and when.
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.
Subscribe to Service Oriented via Email alerts or RSS.
SponsoredWhite 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
- 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
- The True Costs of Virtual Server Solutions VMware In an economic environment that is repeatedly heralding the message "do ... 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
- Hello, I’m a Cloud… and I’m Enterprise Software
- SOA Manifesto: Manes explains manifesto’s aims
- Cyber Monday approaches — should companies clamp down on employee online shopping?
- Popping the buzzword bubble
- Panel: do cloud computing economic advantages break down in enterprises?
Blogs From Our Sponsors
Most Popular Posts
- Why IT can't seem to deliver measurable productivity
- IT project risk aversion 101
- US defense department IT managers describe latest assault on complex and siloed IT systems
- No SOAP for this Navy
- SOA promotes a sea change for the US Coast Guard
- Gartner: 10 reasons why both sides of the SOA debate have it wrong
Top Rated
- No SOAP for this Navy+4 votes
- Popping the buzzword bubble+4 votes
- ARIN CEO reminds: be prepared for Internet numbering expansion+3 votes
- Hello, I'm a Cloud... and I'm Enterprise Software+3 votes
- SOA Manifesto: Manes explains manifesto's aims+3 votes
- Gartner: 10 reasons why both sides of the SOA debate have it wrong+3 votes
- IT project risk aversion 101+3 votes
- Enterprise mashup, defined+2 votes
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
- New Online Dashboard for IT Leaders
-
Read about top issues IT decision-makers face every day, plus get cost-effective solutions to real-life IT problems.
- Learn more >>
- Microsoft Dynamics CRM Online - Free Six-Month Trial for Eligible Organizations
-
Microsoft Dynamics CRM Online provides fast online access, simple contact management and better sales performance for a low monthly cost - the best value on the market today.
- Learn more about the free, six-month trial offer>>
- Reduce risk. Reduce complexity. Increase reliability.
-
A simplified IT environment isn't just less complex. It's also more reliable. Standardize on a single Linux platform with SUSE Linux Enterprise from Novell, and get the world's most interoperable Linux
- Learn more >>
Archives
Favorite Links
IT & business transformation
SOA Blogs
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
- 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
- Email Security and Archiving - Clearer in the Cloud Google The time is NOW for businesses and organizations of all sizes to implement ... Download Now
- Key Strategies for Federal Agencies - Safe and Cost Effective Migration for Legacy Hardware GovConnection The federal government has mandated that federal agencies reduce energy ... Download Now
SmartPlanet
- Thought-provoking progressive ideas on diverse topics that intersect with technology, business, and life, and matter to the world at large. Visit SmartPlanet
- More from IBM
-
- Innovate your business' process model, play against the market, compete against others on our scoreboards and WIN! Try INNOV8 2.0: A BPM Simulator
- Enabling Real-World Business Transformation through IBM Service Management Read the EMA Analyst Report
