The Payoff: Real Business-IT Alignment

All of these challenges underscore how different SOA is from traditional enterprise technology efforts. The CIO must put the technologist hat to the side and become an advocate for business processes. Better knowledge of those processes leads to better technology design, which reduces the cost of maintaining existing systems—something that now accounts for 70 percent to

80 percent of IT budgets, says Schmelzer.

“We’ve been talking for years about IT-business alignment,” says IDC’s Rogers. An SOA lets you actually achieve that goal—if you can develop the architectural vision and execute on it over the long term. The process is not easy, but early adopters like Peck, Metzger and Stubbs would never go back to the traditional IT approach. “A lot of [D.C.] government would not work without SOA,” says Peck.

Challenge 3: Rethink Your Talent Pool

In addition to architecture staff that develop and manage the SOA’s big picture, the CIO will need a development staff that is comfortable with both business processes and the services approach to developing applications. And business experts who can partner with IT on process identification and implementation are also critical—the CIO’s organization can’t do it all.

“Retraining, hiring and redeploying are all needed,” says Rogers, so most CIOs will bring in some key hires experienced with SOA and retrain the existing staff in SOA-oriented thinking. “It’s an ongoing process, so start out small and do a lot of retraining,” says TrueCredit’s Metzger.

Challenge 4: Apply SOA Principles to Your Data Too

Often overlooked in initial SOA efforts is the importance of treating data—not just application functionality—as a service, says ZapThink’s Schmelzer. In an SOA, multiple services residing in multiple applications might combine to execute a business process. If each service uses different data sources, or even the same data source in different ways, the results might not be what you expect, he says.

For example, Metzger enforces strict separation between services that access and store data and those that act on the data, such as performing calculations. He also keeps presentation services—those that format the data for the user or for reports—separate from other services. This helps ensure that all services have the same context for a specific piece of data.

Challenge 2: Take Governance Seriously

Because SOA is ultimately about creating and managing IT processes in support of business processes, governance is critical. “Development organizations are used to building applications, but now they are assembling parts,” says Dennis Gaughan, research director for IT governance at AMR Research. And that development has to be done in a standard way—which can rub developers the wrong way. “SOA takes a lot of the control away [from individual developers], so you get resistance,” says John Stubbs, CIO at Sony Pictures Entertainment, the distribution arm of Sony. Sony Pictures’ SOA efforts have resulted in a common service for managing the licensing rights of movies and TV shows across several lines of business (including DVD sales and theatrical releases) affecting 39 business units (including legal and marketing). The IT group is now using the SOA to deploy common Web services for its SAP Financials processes like accounts receivable.

A way to enforce the SOA principle of reuse is to have a review board that evaluates new applications to ensure they are really needed. Sony Pictures and TrueCredit both use such a board. The review board should include the CIO or CTO, chief architect, key technology and process experts from IT, and key business analysts, says IDC’s Rogers.

By Galen Gruman

May 01, 2006 — CIO — The term service-oriented architecture (SOA) hadn’t gained currency in 2002 when TrueCredit, a subsidiary of the TransUnion credit verification agency, began deployment of an enterprisewide portal. CIO Scott Metzger’s goals were simple: Identify the business processes and the IT functions to be delivered through the portal, and reuse software wherever possible to reduce development cost and speed deployment.

But Metzger soon realized that the effort was about more than this one application; it was an excellent excuse to begin mapping out the company’s most important business processes to create an architecture that would let IT develop and modify the supporting applications easily as business needs changed. Call it SOA or whatever you want, says

Metzger, but for him, the shift in thought that began with the portal application was a turning point in IT’s relationship with the business. “[We have] a much closer relationship with business [now]. It’s a great way to unify the organization,” he says. A March 2006 survey by CIO and Computerworld shows that 77 percent of enterprises adopting SOA seek greater business flexibility.

In his eureka moment, Metzger also realized a key strategy that has guided his SOA effort ever since: “It’s not a technology road map but a business plan. Find a way to articulate the actual business process independent of any technology. That will best protect your SOA investment in the long term.” Since 2002, Metzger has built a common portal and services manager to deliver the company’s various services—including credit processing, payments management and credit monitoring—both internally and to external customers.

The importance of process in SOA means CIOs should be addressing architectural issues at the same time that they consider purchasing or implementing SOA infrastructure, says Ron Schmelzer, a senior analyst at SOA research firm ZapThink. “You can purchase an SOA infrastructure, but it won’t be as useful as it can be unless an architectural plan driven by business process is in place,” he adds.

That focus on process rather than on specific technology is what lets an SOA deliver on its promise of true IT-business alignment. But it also introduces new challenges for CIOs—challenges that stretch IT’s abilities in areas that have been chronically underdeveloped: process and architectural planning. Their staffs will also be stretched. In short, CIOs who expect that they can do SOA the same way they’ve always done technology implementations risk being blindsided.

Challenge 1: Deploy in Pieces But Create a Long-Term Plan

An SOA involves years of effort to get its ultimate result. That’s why respondents to the CIO/Computerworld survey cited the challenge of shifting to an SOA architecture while meeting current business needs as the top concern (63 percent).

The trick is to not deploy SOA all at once, because by the time most “big-bang” efforts are completed, the business needs may have changed and much of the implementation will be outdated, says Sandra Rogers, program director for SOA, Web services and integration at research company IDC (a sister company to CIO’s publisher). Instead, create the architecture and deploy specific services in phases, perhaps by focusing on one application domain at a time or choosing projects based on business urgency. “You can build incrementally,” says Suzanne Peck, CTO of the District of Columbia. In 1999, Peck began reorganizing 370 legacy systems into nine functional groupings in preparation for a new SOA. The services include both new code and Web-services-based interfaces to legacy code, as well as new composite applications.

But until you develop the underlying architecture, you can’t build anything. “How you’re going to manage version 2 [of your services] and beyond is important to think through up front,” says Metzger. “It’s important to understand how volatile a particular business process is.”

Any organization implementing an SOA should create a basic architectural model for a manageable piece of the business, and then apply that model opportunistically to individual projects, using them both to test the model and to deploy the SOA in pieces, says ZapThink’s Schmelzer. That architecture includes identifying all of the business processes, the interactions among them, the specific applications and functions (existing and needed) to deploy them, and the flow of business logic and data to execute the business processes. Identifying these pieces lets you understand common functions that can be standardized across all processes, as well as identify the compliance, security and management requirements.

Be prepared to spend up to a year doing the initial business process and architectural analysis, advises TrueCredit’s Metzger. But that extra time spent up front will pay off exponentially, he says. Today, new services at TrueCredit have only a six-week development cycle. At the District of Columbia, some services are delivered in as little as 12 weeks (more complex ones take four to six months).

1.) Build user-friendly sites that don’t frustrate or annoy users.

Know your users, know their goals and build streamlined paths from the homepage to your goal accordingly. Sites like Nike.com and Apple.com excel at brand image, but have roadblocks when it comes to purchasing.

2.) Create a “brand persona.”

Use the narrative description from the company’s mission statement, a logo in lieu of a face, a tagline from the current ad campaign and bulleted lists of the most important benefits, and behaviors associated with the brand.

3.) Permeate the site with brand image.

Check every page of your site. Reebok’s strong brand position, “celebrating individuality and authenticity,” functions only as a “thin skin,” on its site. It disappears within one or two clicks of the mouse and is replaced with gimmicky Flash apps that convey the opposite message.

4.) Conduct a full brand image review quarterly.

Start with a typical customer goal. Direct reviewers to the parts of the site with that goal in hand and the company’s “brand persona” to remind them what they’re checking for. Make sure each page supports the brand persona.

By C.G. Lynch

December 19, 2007 — CIO — CORT Business Services has adopted wikis and blogs to help foster internal collaboration across different departments and to manage the workflow for its e-commerce site, which rents out home and office furniture and helps companies relocate employees to new locations.

A subsidiary of Berkshire Hathaway, CORT has approximately 2,500 employees spread out across 180 locations. The highly distributed nature of its workforce made it a perfect candidate for a social software suite, notes Lee Thomas, vice president of information technology and product development. “We’re a decentralized company,” he says. “It’s hard to know who is impacted by every decision we make. We need the proper people to stay in the loop regarding relevant information, and stay out of the loop when it isn’t relevant.”

As that comment might suggest, Thomas says most internal communications and project management at CORT had been previously done over e-mail, which had its pitfalls. One of his many project teams that handles software development for cort.com, an e-commerce site that allows CORT customers to sign up for their relocation services or rent furniture, serves as a good example.

Like any website, cort.com gets an occasional software bug. In the past, developers would address that bug and communicate about the process for fixing it by e-mailing each other. Now, if one of them notices it or sets out to fix it, he can post a message on a blog or update a wiki, leaving it there for his or her colleagues to see (and making sure they don’t waste their time trying to fix it simultaneously).

Jonathan Edwards, an analyst with Yankee Group who studies Web 2.0 in the enterprise, says many companies have begun to see the value in bringing these types of technologies into the workplace internally because teams can use them in any way they see fit. “The beauty of these tools is their flexibility,” Edwards says. “They are being used for project management, internal collaboration, and to build customer, partner and developer communities. [Social software] vendors have been blown away with the creativity of their clients.”

Thomas himself is a good example. As a department head, he frequently had to write e-mails updating his team on operational issues and line of business heads who were interested in ongoing IT projects. Since adopting the social software platform, those parties shouldn’t expect to see e-mails from him anymore; he requires that they subscribe to his blog, where he lays it all out. “I’m getting out of the status report business,” he says, chuckling.

CORT’s wiki and blog are served up to employees over Clearspace, a social software platform provided by Jive that is currently being used by 200 companies. According to the Yankee Group’s Edwards, Jive and other social software vendors of the last few years have begun to prove their mettle in the enterprise space merely by showing that companies can work a different way (such as loosening the e-mail noose). “They have demonstrated the soft ROI of having a more transparent and connected application infrastructure for collaboration,” Edwards says.

It’s also pretty cheap. The pricing varies according to the number of users. But assuming a company has 25 users or more, it’s about $59 per user per year.

According to Thomas, much like how blogs and wikis grew up in the consumer space, allowing groups within the company to embrace the technology and use it how they see fit will help in its overall adoption. Right now, of Cort’s 2,500 employees, Thomas estimates 100 of them make contributions and another 200 view it almost every day. Just like the Web, however, he sees it catching on virally. “This whole thing is very organic,” he says, “and I see new groups popping up every couple weeks.

Gartner Inc.’s top 30 locations for offshore services, by region, are:

Americas: Argentina, Brazil, Canada, Chile, Costa Rica, Mexico and Uruguay.

Asia/Pacific: Australia, China, India, Malaysia, New Zealand, Pakistan, the Philippines, Singapore, Sri Lanka and Vietnam.

Europe, the Middle East and Africa: The Czech Republic, Hungary, Ireland, Israel, Northern Ireland, Poland, Romania, Russia, Slovakia, South Africa, Spain, Turkey and Ukraine.

Gartner’s criteria:

1. Language
2. Government support
3. Labor pool
4. Infrastructure
5. Educational system
6. Cost
7. Political and economic environment
8. Cultural compatibility
9. Global and legal maturity
10. Data and IP security

What is it? Ajax is a buzzword that describes a collection of Web-oriented programming technologies—all of them several years old—for creating Web applications that behave more like traditional computer programs.

What does it do? A Web application built with Ajax efficiently delivers additional information to a browser when someone clicks on a button or moves the mouse cursor over a part of the page, without refreshing the entire page. That, ideally, results in Web pages that respond almost as if they were a locally installed program. For example, a video rental company uses Ajax to automatically pop up a movie’s synopsis, complete with a thumbnail image of the movie poster, when a customer moves a cursor over titles in a list of search results. Previously, the site required loading to a brand-new page if a user wanted to find out more about a movie.

What’s in Ajax? It stands for “Asynchronous JavaScript and XML.” (Adaptive Path, a San Francisco Web design consulting firm, is credited with coining the term.) JavaScript is a programming language that provides the interactive features of Ajax; for instance, it manages what happens when someone clicks the mouse. The “asynchronous” part of Ajax uses a piece of software created by Microsoft in 1997, written in eXtensible Markup Language (XML), that retrieves data from a Web server only when it’s requested by the person viewing a page instead of all at once when a page is first loaded, as with conventional Web pages.

Why is this stuff getting attention now? Because some big Web sites have recently provided examples of useful—and fun—Ajax-based applications. Google Maps (maps.google.com), introduced in February 2005, shows street addresses on a map and then lets you scroll in different directions without having to wait for the page to reload. “Sites built using the Ajax approach are easy to use and very cool,” says Brian Goldfarb, a product manager in Microsoft’s Web Platform and Tools group. “It gets you emotionally connected.”

Why else is it interesting? Ajax works with most standard Web browsers and any Web server, unlike proprietary technologies for creating interactive Web applications that require additional software (such as Macromedia’s Flash). Although technically the Microsoft-developed XML code that is part of Ajax isn’t an industry standard, major browsers—including Microsoft’s Internet Explorer and the open-source Firefox—work with Ajax-based pages.

What’s the downside? It’s hard to do. Creating an Ajax application from scratch is like having to build a brick wall but first having to figure out how to create the bricks.

Will it get easier? Yes. Web development tools vendors are delivering better building blocks for Ajax. In September, Microsoft demonstrated Atlas, a set of prebuilt programming “libraries” that wrap Ajax technologies into discrete, functional pieces of code.