“Imagine a world where enterprises no longer purchase software at all!”
That’s how ZapThink’s Jason Bloomberg sizes up the latest potential threat to vendors’ cash cows. The possibility that enterprises will simply tap into the cloud for what they need — rather than shelling out oodles of dollars, euros, rupees, or pounds for onsite software — certainly must be a troubling prospect.
Credit: NASA
One of the things I pondered quite a few times here at this blogsite over the years is how vendors felt promoting a paradigm (SOA) that encourages the use of standardized, hot-swappable software components. In other words, making their software extremely, extremely expendable. Rather than upgrade to the next version of that ERP system, build services around it that do the job required to keep up with the business.
Well, Oracle, SAP, IBM, HP, and Microsoft have been able to capitalize very nicely on service oriented architecture in a very big way, thank you, turning in into an industry in itself — with middleware, brokers, development tools, governance tools, and consulting.
Will things be different with cloud? Jason compares the specter to SOA a few years back — and taking the situation a bit further:
“As their customers started figuring out that SOA success didn’t depend on buying new software after all, but rather was a better way to organize existing IT assets, now cloud computing may replace the need to own those assets altogether.”
Do the platform vendors really have something to fear this time around, or does it mean adopting a new business model — and perhaps, as we’ve seem big time with SOA, buying their way into the new realm with lots of strategic acquisitions?
Jason invokes a couple of hard-won lessons that came out of the SOA struggle these past few years. First, don’t be enamored by the technology. Build the business case, design the service, then decide what technology fills the need. In other words, don’t expect enterprises to be moving en mass to a software-less world just because cloud is this year’s flavor. Sure, cloud will offer a lot of compelling solutions, especially in startup situations (in large and small companies). But, as Jason points out, the element that the cloud requires to succeed in addressing business requirements is governance — this is where years of SOA work and vendor investments will begin to pay off.
In addition, let me add that if anything, there will be a lot of reliance on private clouds and hybrid approaches. Enterprises will be both producers and consumers of cloud-based services. Yes, the lines will blur between software vendors and end-user customers. But either way, that still calls for lots of infrastructure investments by enterprises.
Are users starting to rebel against their information technology departments?
In a piece just published in the latest issue of CIO, Thomas Wailgum ponders whether anti-IT sentiment within organizations is reaching a boiling point. End users in the business are getting fed up with the complexity and inflexibility of their IT departments. The recent economic downturn was the icing on the cake.
Gene Kranz, NASA flight director. Credit: NASA
Wailgum points out that all of today’s enterprises rely heavily on IT to operate on a day-to-day basis. He goes down the list of vital functions — from business development to manufacturing — and challenges: “Try doing any of those without IT.”
Yet, he points out, frustration with IT is boiling over:
“Decades of business-IT acrimony combined with demand for new consumer-oriented Web-based applications (which IT has been slow to embrace) and layers upon layers of accrued tech legacy have boiled into frustration and anti-IT sentiment.”
Wailgum declares this love-hate standoff between IT and the business “the new normal,” accelerated by the recent economic downturn. It’s all about pushing IT to the outer edge of the productivity envelope to help meet fast-moving business targets in a fast-moving global economy.
Wailgum seems to have tapped into a vein of frustration that clearly is being felt. But I’d like to paraphrase the supposed response of Gene Kranz, NASA flight director, in the movie Apollo 13, when told that the accident that took out the Apollo’s service module would be the worst disaster in NASA history. His response: “With all due respect, sir, I believe this is gonna be our finest hour.”
Some see the recent economic trough as one of IT’s finest hours. For example, a survey off 444 C-level executives by McKinsey & Company at the end of last year found that in the wake of the recent economic hurricane, many non-IT executives seemed to have developed a healthier appreciation for their information technology functions. Business executives, overall, seem pleased with the way IT helped organizations navigate the rough seas. IT leaders themselves, however, feel they could be doing better.
Still, there are areas where a large, complex, creaky IT structure may be holding things back. For example, in a survey I conducted as part of my work with Unisphere Research/Information Today Inc. and the Oracle Applications User Group, we found that while many companies aspire to “compete on analytics,” decision-makers still wait days, weeks, and even months for reports on the state of their business. Most still do not have access to analytic tools.
So, there are many different views on the complicated relationship between IT and the business. To help smooth things over, and hopefully quell an end-user rebellion, Wailgum makes the following recommendations for reducing the rift between IT and business:
CIOs and IT managers, change your mindset: “Engaging with business has to change from an autocratic mindset to a partnership one,” Wailgum writes. “Traditional business processes resembling ‘replication and incremental refinement’ have to shift to ‘disruptive and transformative’; infrastructure management moves from ‘reliable and expensive’ to ‘flexible and cost effective.’”
Biz speak only: “Today’s harsh business climate necessitates clear and consistent communication… without that communication piece, they just aren’t getting the traction and acceleration that they need right now.”
Know your customers — all of them: It’s imperative that CIOs and IT understand the ever-changing technology wants and needs of not only internal users and managers but their company’s external customers.”
Don’t fear failure: “The imperative for CIOs is to explore and experiment with so-called disruptive technologies (Web 2.0, social media, cloud computing) that users and customers have embraced.”
Be ready to be asked for more than ever before: The new mantra for IT departments is ‘cut and grow,’ which requires deft management.
One of the most vexing — and most criticized — aspects of service oriented architecture has been trying to establish and measure its impact on business agility.
Whitney Bank, New Orleans. Credit: Wikipedia
This is the vaunted second phase of SOA, in which results move from more localized benefits, particularly developer productivity stemming from spending less time rewriting code that already exists in available services, or not having to go in and tear apart hard-wired back-end applications because someone needs a new interface.
However, what exactly is business agility? Faster time to market with new products or services? Check. Greater responsiveness to customers? Check. Ability to rapidly absorb newly merged subsidiaries? Check. Ability to rapidly bring new partners or suppliers online? Check. Ability to get real-time or near-real-time information to decision makers? Check.
SOA can play a role in enhancing all of these areas, but it’s exact return on investment from a business perspective is difficult to measure. By extension, it’s even more difficult to ascertain the contribution of an SOA-enabled infrastructure to the increased revenues that may be flowing in as a result of this greater agility.
This is simply something that’s going to take time to work through and figure out as SOA practices mature within organizations. In the meantime, building a business case for a SOA-based transformation requires working with facts close to the ground.
That’s the way Stan Limerick, director of technology strategy and architecture for Whitney National Bank in New Orleans, built a winning SOA formula, helping the bank is attaining measurable results on a number of fronts. I recently had the opportunity to speak with Stan about the program, and he explained how the key to Whitney’s SOA success is close collaboration with the business — and setting realistic expectations from the start.
To track the progress of the implementation, Limerick meets every month with the bank’s financial managers. “We go through all of the cost-savings aspects of the original business case. To see how were tracking to that. This wasn’t a fire-and-forget business case. We’re actually tracking month to month, to see if we are realizing the savings and benefits that we expected to see. And so far we slightly exceeded what we had in the business case.”
These savings and benefits come from two areas — cost savings within the technology group, and through operational efficiencies outside of the technology group. “It was based on process efficiencies and staff reductions across the bank, and we built the business case on a percent reduction base versus non-interest income.”
While Limerick’s team was able to build a strong business case on cost savings and efficiencies, they did not extend that to revenue-generation capabilities, at least not for now. “The business case stood on its own without that, so there was no reason to go there. Those numbers are always going to get pulled into question. We decided it wasn’t even necessary, so let’s not go there. We were able to give the on-the-line banker a lot more information about their customers, and things like that.”
Whitney began its SOA journey in earnest about a year and a half ago, when Limerick sought to address the multiple interfaces and legacy systems, some supported on a mainframe, and representing a range of messaging styles and interfaces. “We had everything from screen-scraping or sockets, you name it. This was our chance to standardize on something, and do it in the same style and form across the bank both for internal applications, as well as ASPs and business process outsourcers.”
The scope of the integration was driven by the business units. “It was a highly involved process,” Limerick says. “We had a fairly good functional taxonomy of the entire bank. It gave us a good way of lining up requirements for doing product selection and evaluation. The business themselves did the functional scoring, not IT.”
The SOA effort was not presented to the business as “SOA,” Limerick explains. “We explained to the business that their way of integrating and providing data, as well as integrating applications, is actually hindering them in several ways. If they wanted to go in and change suppliers, it was a significant effort, because they had all point-to-point interfaces, and we had to figure out what all would be impacted by that change. If we could get that decoupled, then they would have a lot more leeway in moving to better suppliers to give them competitive edge in market changes.”
The SOA-based infrastructure enables business users to more easily swap out suppliers as needs change. “It gave the business guys a lot more leeway than what they would before,” Limerick says. “It helped us on introducing new products, because its a much simpler environment.” Limerick says the bank currently has less than a third of the interfaces it once had — numbering more than 850. “This means that I can actually make changes and improvements in the environment much faster than I could before.”
The new SOA-aware core banking application was built on IBM’s WebSphere Process Server, IBM WebSphere DataPower appliances, and WebSphere Service Registry and Repository.
However, in a new post, the ever-sharp Mike Kavis says smaller organizations — especially start-ups — have natural advantages that position them well for building service-oriented approaches to their IT. There’s that fresh, greenfield aspect of course, but Mike says there are other factors at play as well. Experienced in SOA-based projects in both medium-size companies and startups, he weighs the differences. (Some of the issues in medium-size organizations may be amplified in large organizations):
Legacy: Medium-size companies need to focus on integration of siloed systems. Startups can start fresh, with a blank sheet of paper, and business technology can be service-oriented right out of the gate.
Organizational change and politics: Medium-size companies encounter resistance and conflict between groups with entrenched processes and solutions. Startup teams can sign on to an agreed-upon IT roadmap from day one, and can understand how SOA could deliver efficiency, agility and connectivity to partners.
Governance: With their various application silos and groups, medium-size companies have different governance models “ranging from mature to chaotic.” Startups can establish ownership of various architecture layers from the beginning, avoiding the need for large governance boards and charters.
Agility: Medium-size companies need to spend more time getting management, documentation, and communication lined up, so everyone is on the same page. Startups can get things done with small, collaborative teams.
Capital: Medium-size companies have a leg up on this one, since they may have more access to capital. They can better afford to bring in consultants and equipment to get things moving in the right direction. Startups need to build up gradually.
As we pull out of the recent financial crisis, there’s been no shortage of finger-pointing as to who’s to blame — banks, Wall Street, the Fed, the regulator, Fannie and Freddie, to name a few. But one IT industry expert says the blame should be boiled down to ineffective information technology.
Expert: apply SOA to risk management systems, ASAP.
My colleague here at the ZDNet blogging community, Andrew Nusca, reports on a conversation he just had with Sudhakar Ram, chairman and co-founder of Mastek, who pins the blame for the recent economic meltdown on “aging, overly-complicated IT systems.”
The original trigger of the crisis, the subprime mortgage debacle, came about because there wasn’t an effective way in existing risk management systems to trace the origin of home loans, many of which got parsed up and embedded into other financial systems, Ram says.
“The risk-management systems need an overhaul. The risks associated with derivatives, all of them are based on a series of assumptions… Almost 30 to 40 percent of critical decision-making systems are actually Excel spreadsheets, in large organizations… Everyone has their own small reality.”
The solution, Ram says, is move to greater service orientation of these systems. That way, decision-makers can still rely on the processes and information supported by legacy systems, while easing into a gradual migration to next-generation technology:
“The thing that we’ve found [is that] the new SOA approach actually helps with a gradual transformation. The approach we have taken with legacy programs is to put in an SOA layer and a front end that can work with multiple back ends – a complete SOA-enabled platform.”
That’s because it’s too risky to attempt to rip and replace these legacy systems, he points out. SOA offers a way to retain the original business logic embedded in these systems, since “nobody knows what is inside. These systems have been put in place and the people who knew what they were supposed to do are all dead or retired.”
An enterprise architecture approach to these problems is the key, he adds. Establish a five-year roadmap for systems, and migrate on an incremental basis. SOA approaches will ease that migration.
In my last post, I described how SOA will be enabling the systems that defend the universe. Now, here’s another proposal for SOA approaches to defend our financial system. Hopefully, no one accuses me of taking hype to a whole new level. SOA has its issues, is often misunderstood, has often been hijacked by vendors and yes, played to the hilt by analysts. There is plenty of uncertainty about its promises to deliver business agility and flexibility — what is that and how can we measure it? But if we don’t move to service oriented architecture, what’s the alternative?
Gary E. Payton, US deputy under secretary of the Air Force for Space Programs, recently testified before Congress, seeking appropriations for the military space program, which includes worldwide communication; global positioning, navigation and timing; global missile warning; weather; and satellite launches.
Credit: Lockheed Martin
Payton also discussed the “Space Fence” and “Space-Based Space Surveillance” programs, which will enhance “Space Situational Awareness” — sounds like a call for complex event processing capabilities. These programs will be dedicated to tracking objects orbiting or approaching the earth. The IT underpinning these programs will be based on service-oriented architecture, Payton testified. He also referenced JMS, but no, not Java Message Service — in this case, it means “Joint Mission System.”
The need for increased space protection of our space assets is paramount, and requires enhanced Space Situational Awareness (SSA) capabilities and a legitimate battle management system. We need improved accuracy, responsiveness, timeliness, and data integration to support the warfighter. Our FY2011 budget request continues development of the Joint Space Operation Center (JSpOC) Mission System (JMS) to provide this capability and replace our aging mission systems. The JMS program will provide a single, theater-integrated, command and control, information technology system to allow informed and rapid decisions with real-time, actionable SSA. An operational utility evaluation effort will deliver the foundational infrastructure and mission applications to deploy a services-oriented architecture (SOA) with user defined applications.
Many have questioned the ability of SOA-based systems to deliver business value. Can we rely on SOA-based systems to defend the universe?
Despite all the tools and platforms available for integration, hand-coding is still rife in enterprises. Is this a bad thing? Loraine Lawson says maybe it is, maybe it isn’t — and observes that a lot of IT leaders find it to be the quickest path of least resistance when something needs to get done.
What’s the best way to alleviate all that inefficient hand coding of integration projects, and move to a better, more automated or at least process-oriented way? Loraine outlines seven steps that will set you enterprise on a more productive path:
Make a commitment to fix integration — strategically.
Break down IT silos, which create a mish-mash of tools and redundant work.
Get the business involved.
Create an integration portfolio.
Form an Integration Competency Center to bring the business and IT to common ground.
Invest in standards to ensure consistency in your efforts.
Invest in a data integration platform. “Time and time again, the experts say it’s worth the investment,” Loraine says — in the long run, it’s cheaper than paying developers to hand code each time a project comes along.
What’s the difference between enterprise mashups and the rapid application development (RAD) tools that we saw emerge in the 1990s? Is there anything really that new or unique about enterprise mashups?
Rapid application development (RAD) tools brought lighter, smarter development in the 1990s. Now, mashups bridge RAD to SOA.
RAD tools revolutionized the way many applications were built, enabling developers to quickly churn out lightweight applications, especially for desktop environments. RAD, based on dragging-and-dropping rather than coding, started with Visual Basic, followed by tools such as PowerBuilder and Borland Delphi.
However, Ogrinz observes, as the world shifted to SOA and Web-based applications, “we lost the ‘R’ in RAD. Architectures became more complicated as the industry embraced products like J2EE servers and ESBs.”
Enterprise mashups bring back the capabilities to quickly build new services that can access data and applications from the back end. There’s even an additional twist — non-technical end users can create their own solutions in many cases. I like the analogy Ogrinz provides to describe the way mashups have changed the equation:
“RAD in the 90’s consisted of IT going door-to-door to build solutions for the business. Later, with SOAs, IT built internal services and then assembled them to meet specific use cases. It’s almost like we were carpenters and if someone wanted a bookcase we’d go into their house, ask what they wanted, and then build it for them. Today, we can be more like Home Depot. Enterprise services are the lumber, nails, paint while Mashup products are the tools that pull them together. We still have general contractors (our existing IT staff) but we also have plenty of do-it-yourselfers in the form of non-technical business users. Self-serve IT seems poised for explosive growth.”
Sometimes, the best path to success is knowing very clearly what doesn’t work.
Steve Jones, who initially coined the notion of SOA “anti-patterns” a few years back, has published a new set of no-nos he calls “anti-principles.” Understanding these anti-principles is probably more important than understanding SOA itself, he says. (Thanks to Mark Little for surfacing this gem.)
Principles that are well understood to be part of the SOA equation include loose coupling and clear interfaces. However, it’s not understanding the anti-principles that trip up SOA efforts, he says. Three examples of anti-principles include the following:
Small return values: A carryover from batch thinking, this is “just return a code and description rather than returning a decent amount of data.”
Direct calling: “People just get a WSDL and consume it directly without any proxy or intermediary.”"
Interface generation: People design interfaces up front, versus generating interfaces from code.”
There’s plenty more that can be said about this, and I urge readers to contribute their examples of anti-principles. Just some additional suggestions for anti-principles, based on the guiding principles laid out in the SOA Manifesto:
The organization doesn’t know what it wants, let’s just go ahead and create this for them — they’ll thank us later: Yes, many organizations don’t know what they want or where they’re going. But creating SOA-aware services and infrastructure without their input will result in another stovepipe.
This new application server environment we’re putting in will go a long way in finally getting applications service-oriented: Maybe, but SOA is not about relying on products to make it happen.
Designing single-purpose services: There are many cases where single-function services make sense. However, the design of some services need to be considered for the long run.
Are we straining under the weight of an over-reliance on information technology? Is something ready to burst? And when something does, will fingers be pointing at IT and software creators?
Arthur C. Clarke predicted a software calamity with HAL 9000 in 2001: A Space Odyssey, when a computer, programmed to complete a mission, kills most of the occupants of a spacecraft. But there are plenty of real-life — and recent — examples of IT gone wrong. Toyota is dealing with the most massive recall in its history (for software controlling the pedal assembly). A recently merged bank locked customers out of their accounts for two weeks (as they attempting to merge two IT systems). A few weeks back, The New York Times ran an article on how a number of patients were overdosed with radiation with disastrous and tragic consequences.
We’re relying more than ever on systems and technology for our day-to-day existence and commerce, and at the same time, the impact of any system glitches are magnified to the nth power. However, don’t blame software creators when things go wrong. Look at corporate cultures that fail to provide the tools and support that provide for good governance.
I just co-presented a Webcast with Jeff Papows, CEO of WebLayers and formerly president of Lotus, on this topic, and what business and IT people need to do to manage the risks of glitches. As Jeff put it, “we have all the ingredients here for the information technology version of a perfect storm. As of January of 2010 there were six billion networked things talking to other things — whether that’s local area networks, wide area networks, hot spots, Bluetooth or whatever. Its an immense of amount of everything from handheld computing to other Internet-savvy devices interconnecting in an unprecedented volume. There are literally a billion transistors in place for every carbon-based bi-ped homosapien life form on the planet. The strain on our infrastructure is more extreme than its ever been.”
Add to that a backdrop of a tough economy, with IT and support departments being cut to the bone.
In attempting to mitigate or prevent a catastrophic software glitch, or chronic series of events, we need to ask, who takes responsibility for these things, who can prevent such things? There are some issues that will be laid at the feet of information technology managers, and many others that may be well beyond the control of IT. As NASA, the most technically proficient organization on the planet, concluded after a lot of soul-searching following both the Challenger and Columbia shuttle disasters in 1986 and 2003, the issue was one of communications, management, and a corporate culture that may have built up a bit too much hubris, with no place for those who challenge conventional wisdom or saw issues that were able to surface among the managers.
I have a gut feeling that we may see a similar pattern emerge as Toyota finally has a chance to step back and examines its own operations in the wake of the recent recall of accelerator pedals.
The way to avoid or at least mitigate the risks of a horrendous glitch? Encourage environments of innovation and automation. “The complexity curve is not going to flatten,” Jeff pointed out. “Whether you’re Ford, Toyota, Bank of America, or AT&T, I don’t care who you are, we’re all forced to do more with less. As a consequence, the only thing in my view we can do is do for ourselves what we’ve promised to do for the market all along, and that is innovate and automate.” Tools such as design time governance, quality assurance, and security middleware can help, he says.
But tools alone won’t do the trick, he adds. “There is no silver bullet.” What is essential is a corporate culture and management structure that encourages managers and practitioners to develop and follow best practices. “Glitches are no longer something that happens in the backroom. They’re something now that affects the quality of our companies’ success in the marketplace. Therefore in my view, its not just a matter fo IT management — it’s corporate management and the cultural freedom to be inventive, and allow computer science professionals who are on the front lines of our companies to acquire the tools that they need in order to get ahead. You cant simply solve these problems by working harder.”
Become a learning organization in this regard, and learn from the experiences of others, Jeff urges: “It starts with gathering those best ideas and best practices and poicies. It’s like anything else, most of us didn’t invent the wheel, but we’re all big fans.” Establishing centers of excellence also can go a long way to codifying these best practices into company systems and processes.
I added that we need almost a Y2K-style focus to the issues. Industry veterans may remember how back in the 1990s, for the first time in many cases, IT sat down with the business to map out exactly what kinds of applications it was relying on, and what the potential impacts would be on the business is any one of those applications went down. Risk management exercises — reviewing likely scenarios of failure and preparing for them — should be a part of every IT project.
Huge catastrophic glitches aside, the day-to-day glitches also add up, and a buggy e-commerce site could severely dampen business. As Jeff pointed out, “these days, consumers vote with their mouse.”
I just posted a report that said the US Secret Service is still running its operations on 1980s mainframes. The Secret Service does see modernization as a priority, and overall, it appears that most federal agencies are working toward modernizing their mainframe systems.
An informal survey by Micro Focus — a vendor with a serious stake in mainframe modernization — finds at least 72% of federal IT managers say that they are planning to build application modernization into their budgets within the next six months to two years. About 40% plan to budget for modernization within six months to one year.
Micro Focus also found that despite the recent buzz around cloud computing, only six percent of those surveyed stated that they planned to adopt cloud computing as part of their modernization efforts. The top modernization objective cited by respondents was to move to Web-enabled systems (54%), with Windows cited as their systems’ most likely platform (38%) after modernization.
Long-term cost savings was noted as the most important benefit of modernization, with ease-of-use a close second. A respondent from the General Services Administration, for example, notes that business requirements are one of their organization’s most important motivators for application modernization, and that they are planning to budget for this effort within six months. GSA’s end objective is to take advantage of various open source tools.
The hype is reaching a point where any and all services are being envisioned as cloud applications. Geek & Poke’s Oliver Widder points out that there may be limits to what the cloud can do, however.
The statistic we hear bandied around is that 80% of the world’s data and processing take place in mainframe machines. The mainframes on the market now — IBM’s System z — are bulletproof servers that support all types of Web and non-Web services and applications. They will run countless instances of Linux, Unix and even Windows either virtualized within logical partitions or as part of a smaller-processor “specialty engine” that can be snapped into the system.
However, the mainframes that were built in the 1970s and 80s may be somewhat limited in what they can support. Apparently, according to news reports, the US Secret Service, which has global operations, is still stuck in the 1980s when it comes to IT. According to US Senator Joe Lieberman, the agency still runs a mainframe it initially purchased in the 1980s. The report notes that users “are at times unable to conduct searches from one system to another.” It is estimated that the Secret Service needs about $187 million to update its system, but only has received $33 million so far.
As reported here at this blogsite, various US government agencies have been aggressively pursuing service-orientation of their systems, along with cloud, virtualization, and open source, to better integrate and manage huge expanses of stovepipes.
A model the Secret Service may follow, the report suggests, is the FBI’s new $451 million Sentinel system, which will enable “agents to use a Web-based system to incorporate the FBI’s old existing files.” A couple of years back, the FBI also launched an SOA-based initiative called Regional Data Exchange, or R-DEx, a series of information sharing pilots with regional databases. Under R-DEx, the FBI has created plug-ins to Justice Department databases for four regional law enforcement data sharing associations, with more to come — using an SOA registry built with off-the-shelf IT products.
Since it came about in its current form in the early-to-mid 2000s, service-orientation (mainly focused on applications) has existed in a separate world from data management.
Problem is, an SOA-enabled infrastructure with bad data flowing through it can be useless, and even dangerous. Remember how Neal Fishman compared SOA to a mosquito that can deliver payloads of bad data (”viral data”) at lightning speed all across the enterprise — pandemic style — before it can be stopped?
Wanted: advocates who can bridge the chasm between the SOA and data worlds.
Now, we’re seeing the launch of the SOA Data Integration Architect Community (SDIAC), an online community focused on the value of data integration and data services in agile architectures such as SOA, promising to bring the data and SOA worlds closer together. Such an organization will definitely bring support to SOA proponents struggling to address data quality issues, and data architects seeking to service-enable their environments.
One of the moving forces behind the creation of SDIAC is Informatica’s Ash Parikh, a colleague of mine who has been a long-time proponent of data services within a SOA context. While Ash started the ball rolling, he prefers to take a background role in the interest of the vendor-neutrality of the group. At least initially, Informatica is supporting and hosting the SDIAC site. (Disclosure: I am a guest contributor to Informatica’s Perspectives blogging community.)
So the SDIAC will be led by none other than Dave Linthicum, an independent authority on enterprise and data integration, SOA, and cloud computing. As Dave notes in a post over at Perspectives, he views this community “as being sorely needed, considering the lack of understanding of SOA data integration out there today.Those charged with defining and building core IT architectures are not likely to understand the best practices in defining the architecture for the data up to the services, and up to the processes.They are then left with architectures that are difficult to change, and don’t completely take advantage of the data assets.”
Dave also provides three reasons to consider involvement in SDIAC:
1) To become involved in the last mile of SOA – the need to deliver timely, trustworthy and relevant data using data services;
2) to network with peers and exchange knowledge; and
3) to create a nurture new ideas that will move the SOA-data services connection forward.
Another good reason for engaging with SDIAC is that it will help SOA proponents better communicate their ideas and requirements to the data folks, and likewise, helping data managers better understand the role of SOA as a way to get the right information to decision makers and applications. And, for both groups, it can help provide insights and perspectives to approach and sell data services to the business.
And, as we move deeper into emerging areas such as complex event processing and business activity monitoring, SOA can provide the framework to help assure the relevance, accuracy and timeliness of data moving through analytics systems.
“For all its goodness, REST sometimes feels like trying to fit a square peg in the proverbial round hole. Some interaction patterns just don’t lend themselves well to the REST approach…. With WS-*, on the other hand, we get a square peg to fit in a square hole. The problem there is that the peg is twice as wide as the hole.”
- William Vambenepe
In a new post, Oracle’s William Vambenepe, a REST proponent, says there are some situations where the REST protocol may not always be a good fit. Here’s a few of his observations on some “round holes”:
Long-lived operations. “You can’t just hang on for a synchronous response.”
Query: “I’ve seen proposals that create a ‘query’ resource and build it up incrementally by POSTing constraints to it. Very RESTful. Very impractical too.”
Events: “You quickly end up worrying a lot more about firewalls and the cost of keeping HTTP connections open than about RESTful purity.”
The afterlife: “How do you retrieve data about a resource once it’s gone? Which is what a DELETE does to it.”
There’s been an ongoing debate for years between proponents within the WS-*/SOAP and REST worlds. The bottom line is that each has a role to play as systems and infrastructures are stood up and built out in a service-oriented way.
Despite what some vendors have said, service oriented architecture will not solve world hunger.
And there are plenty of voices that say that SOA actually accomplishes nothing at all, because it was cooked up by vendor marketing departments. As Loraine Lawson reported reported last week, small to medium business managers don’t see the point in it.
Plus, many companies that have bought into SOA are still in various stages of SOA-enabling pieces of their systems and operations. There are few, if any, pure SOA-enabled organizations out there. It’s still a work in progress.
Randy Heffner of Forrester reminds us once again, however, that beyond vendor spiels, SOA has a very high-level purpose, to free up businesses from the underlying technology that has been choking them for the last two decades. Ultimately, he says, SOA is more than SOA — that it “provides a broad foundation for a much larger shift in business technology architecture that goes far beyond SOA itself.” In fact, Randy adds, Forrester surveys have found that 38 percent of Global 2000 SOA users say they are using it for strategic business transformation — not for simple little integration projects or code reuse.
This may sound grandiose, but Randy lists at least seven down-to-earth examples of where SOA can take an organization:
SOA aligns software with the business.
SOA creates a portfolio of business capabilities.
SOA brings business capabilities where they are needed.
SOA facilitates business process management for business responsiveness.
SOA supports event processing for early warning.
SOA makes predictive analytics possible for action that anticipates future problems.
SOA contains rules and policies for business flexibility.
I’d like to add my own thoughts to Randy’s list, and that is that SOA brings business partners together into a common collaborative environment. Companies and departments can make services such as inventory checks and purchasing available to partners — you can even call this private cloud computing.
When the economic downturn first began to erode IT budgets back in late 2007 and early 2008, there were fears that service oriented architecture projects would be the first thing on the chopping block. These fears were justified.
Business-driven SOA: ‘obvious to say, difficult to achieve’
Businesses need to whittle down their expenditures to the things that have the greatest impact on growth and sustainability; many SOA projects were mired in optimizing technology more than optimizing business. Hence, Anne Thomas Manes’ declaration last year that SOA was on the skids. When SOA first hit the enterprise mainstream a few years back, most shops focused heavily on the technical aspects of standards, tools, and making it work.
However, the recent recession may have knocked some sense into companies and SOA proponents, with the recognition that successful SOA needs to be tied as closely as possible to the business. I recently had the opportunity to sit down with Steve Ross-Talbot, a co-author of the SOA Manifesto, and principal with Cognizant, an IT consulting firm. Steve discussed about why business value is so important to service oriented architecture. (Listen to the podcast here; full transcript of our discussion available here.)
Steve has been working with numerous companies implementing SOA, and finds a common malady that consistently pops up in projects: the technical requirements overwhelm the business needs. Steve reports he often walks into projects where technical thinking reigns.
He illustrates a situation with one large client, which is involved in a workflow management project. “The only way of getting this right is to ensure that the service layer is subservient to the business value that those other workstreams have to deliver.” This should be the primary task of the enterprise architect — to make sure the business needs are top priority, he adds, noting that “it’s an obvious thing to say, but it’s a very difficult thing to achieve.”
The recent economic downturn really helped to gel SOA thinking around the direct business requirements expected to be delivered. “If you look perhaps four or five years ago, the beginning of this sort of SOA genre, people were going down the SOA route without any sort of view of business value at all,” Steve observes. “And as the economy fell into — I think got more difficult to get budget, people started to look more at business value in general.”
Of course, even the rotten economy still didn’t shake the techno-focus on SOA, Steve observes. “It’s quite common for me to go into customer sites and for people to ask, ‘how do I sell SOA?’ And of course, you can’t because you can’t buy it. And so it always comes back to well, you have to have the business focus… it’s kind of a techno-economic piece of engineering in order to sequence things correctly so that business value gets delivered, and budget gets relief to do the next phase. And as a result, you start go build up a better way of managing reuse and handling change, and all of the other value statements then coming to their own. But this one drives everything for me.”
Loraine Lawson recently delivered some disturbing news for SOA proponents everywhere — revealing the results of a recent informal survey that showed that a majority of mid-market CIOs “said they had no current business need for SOA,” which was roughly twice as many as said they had deployed SOA.
In bare-bones IT operations, SOA may be an unnecessary luxury
Loraine said two CIOs she spoke with seemed jaded by all the SOA hype over the years, noting that “they believed the concept was a sales tactic for selling them something they didn’t need – and were already doing with modular programming.”
One CIO already had an IBM System i running the business (which I still prefer to call AS/400, thank you). Small wonder their needs are met — AS/400 is the most underrated machine ever made, and always at least a decade ahead of its time.
Nevertheless, Loraine correctly points out that these CIOs that reject SOA have small, bare-bones IT operations. In many ways, SOA is still a luxury for well-endowed organizations with sizeable IT staffs. When it comes to running the business at ground level day to day, you need to do what needs to be done — forget about mucking around with creating reusable “services.”
Another factor is that business managers — particularly in smaller organizations — aren’t exactly banging on CIOs’ doors demanding SOA. They want profitable results and information on what’s selling and not selling.
Of course, the mid-market is the prime candidate for cloud computing, and this is where the value of service orientation will ultimately be realized, on an enterprise-to-enterprise scale. But for applications within the infrastructures of smaller enterprises, SOA is still beyond reach.
Still, the more a business of any size can service orient, the better. SOA is an extension of enterprise architecture, and EA is important at any level. Let’s not forget what Mike Kavis and Brenda Michelson told us a few months back — that enterprise architecture is just as important for small businesses as larger ones. Remember, just as is the case with SOA in an ideal world, enterprise archictecture is not about jumbo frameworks and rigid governance, it’s about creating a set of values and practices for capability delivery. 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.
So EA and service orientation is applicable for all size companies — especially as smaller companies become more involved in the cloudsphere.
I just saw snippets of a recent Input market research study that predicts the federal government will be spending plenty over the next few years on five leading technology initiatives.
SOA: The federal SOA market will grow from $330 million to $660 million, at a compound annual growth rate (CAGR) of 17%.
Cloud: The federal cloud computing market to grow from $370 million in 2009 to $1.2 billion in 2014 at a rate of 27%.
Virtualization: The virtualization market will grow from $800 million to $1.4 billion or roughly 12% a year.
Open source: Federal government spending on open-source software is expected to grow from $290 million to $430 million, a rate of 8%.
Geospatial: The federal market for geospatial technology is expected to increase from $860 million to $1.4 billion, at a rate of 8%.
“Nearly half of federal and IT industry professionals surveyed by Input believe these technologies will have a major impact on their technology environment despite concerns over security and up-front costs,” the report states.
The federal government — and in particular, the Department of Defense, has been doing a ton of work with SOA. One of the leaders in this area is Dennis Wisnosky, the business mission area chief technical officer and chief architect at the Office of the Deputy Chief Management Officer at the US Department of Defense, who I met at last year’s SOA Symposium.
Along with incredible charity work, he has been working tirelessly to bring a common set of standards and protocols to the DoD’s procurement and administrative systems, as well as service-oriented principles, and his work is worth emulating across the private sector.
Dennis was recently interviewed by Rutrell Yasin of DefenseSystems.com about the progress of the effort. The problem for the Defense Department’s Business Transformation Agency was engineers and developers tended to work in silos, and end up developing systems that duplicate services and have propriety interfaces that can’t work easily with other systems.
The solution has been the development of concepts called Primitives, Common Vocabulary and Design Patterns, according to Yasin’s report. The Department of Defense Architecture Framework 2.0 is the foundation for architecture Primitives. Primitives are a standard set of viewing elements and associated symbols mapped to the framework’s Meta-Model concepts and applied to viewing techniques.
According to Wisnosky, BTA is applying Primitives based on Business Process Modeling Notation (BPMN). Also, “the idea of Primitives fits nicely into service-oriented architecture,” Wisnosky said. “SOA represents the first time in the information technology world where it is clear how IT and business fit together. So an SOA pattern made up of Primitives that are associated with business processes could execute those business processes with standard services.”
There’s been a lot of SOA developments emerging within the US Defense Department. In another piece of news, a new cybersecurity initiative sponsored by the US Air Force seeks to harden service oriented architectures against outside threats.
Sami Lais, writing in Washington Technology, says a five-year, $2.9 million Air Force Research Laboratory award “could change the way DoD — perhaps the world — approaches information security.”
How is this so? Lais says the USAF’s Advanced Protected Services program is gearing up to “enable networks to withstand attacks that are as yet unknown, limit the effectiveness of the attacks, slow the attackers’ progress by building multiple layers they have to penetrate, let them diagnose the attack more quickly,” and “help them react and recover more quickly and completely.”
Jim Loyall of BBN Technologies, chief scientist and program manager on the project, is working with a team that is concentrating on developing new approaches to better protect DoD SOAs against malicious attacks. The team is building extensions to the middleware stacks in SOA, and using strategies such as creating “crumple zones,” or proxy layers between the service and users allows different users to share the same services. “Users go into this initial buffer area, where much of the service functionality is repeated,” Loyall is quoted as saying. “If an attack succeeds, it’ll get some initial success, but it won’t go past that proxy layer to the service itself, and other users will be uncompromised by the attack.”
Joe McKendrick is an author, consultant and speaker specializing in trends and developments shaping the technology industry. See his full profile and disclosure of his industry affiliations.
Joe McKendrick is an author, consultant and speaker specializing in trends and developments shaping the technology industry. See his 
