SOA Success? Focus on Process and Architecture (4)

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.

SOA Success? Focus on Process and Architecture (3)

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.

SOA Success? Focus on Process and Architecture (2)

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.

SOA Success? Focus on Process and Architecture (1)

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).

The Do’s and Don’ts of successful interviewing

Robert Half Technology, a technology staffing organization, offers this simple list of what you should and shouldn’t do in a job interview. My comments are in brackets.

Do:

• Arrive on time.
• Greet the interviewer by name. [Not his or her first name though until you are issued the invitation.]
• Smile and shake hands firmly. [However, making a good impression is not dependent on how many knuckles you crush.]
• Look alert and interested at all times. [Turn off the cell phone and PDA. Somebody’s going to post in the discussion and ask who’d be stupid enough to leave those on in an interview. I’ve been a witness to it; they’re out there.]
• Speak firmly, clearly and loudly enough to be easily understood. [[A good suggestion but you just know someone reading it will go overboard, yelling and annunciating like a tourist in a foreign land.]
• Look the interviewer in the eye while speaking. [If you’re shy this can be hard to do, but it does help.]
• Structure your comments in a positive manner. [If you’re negative in a meeting in which you’re supposed to impress someone, what does that tell the interviewer about how you’ll be on the job?]

Don’t:

• Exhibit overbearing, overaggressive, or egotistical behavior. [You don’t have to be brash or smug to come across as self-confident.]
• Show a lack of interest or enthusiasm about the position or company. [Why even show up if you’re not interested?]
• Appear excessively nervous. [This is easier said than done if you are actually, well, nervous, as most of us are in interviews. Just try to take some deep breaths beforehand and prepare yourself for possible questions.]
• Overemphasize your compensation. [It was always a red flag to me as a manager when a job candidate asked what the salary was in the first 15 minutes.]
• Make excuses for unfavorable factors in your work history. [It’s tempting, I know. But taking responsibility for yourself is the mature thing to do.]
• Disparage past employers, managers, projects or technologies. [This would tell me that you’re going to do the same thing as an employee working for me.]
• Answer only “yes” or “no” to questions. [It’s pretty awkward when you ask what you think is a probing question and get only a one-word answer in return. Don’t rattle on and on but try to expound a little just to show the interviewer that the wheels up there are turning.]

Four steps to a better Web site

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.

Increase the visibility of your resume with keywords

Have you been submitting resumes and not hearing back? A piece on dice.com suggests it may not be your lack of qualifications but more of a lack of keywords.

Keywords are phrases that communicate your job skills, responsibilities, and/or functions. The more you reference keywords that are contained in the recruiter’s search, the more likely you’ll get calls. Here’s some advice from dice.com:

First, be aware that keywords are best when they refer to hard skills. In other words, “network engineer” and “Help Desk agent” are likely to get more direct attention than “team player” or “multi-tasker.”

The physical location of keywords is also important. Dice says, “Providing a summary of keywords at the conclusion of your resume is an effective way to assure that your resume is selected during database searches. However, to help move you to the interviewing stage, list your keywords near the top.” Career coaches suggest including keywords in the top four to five inches of your resume because the recruiter won’t look beyond that when quickly reviewing a batch of candidate resumes.

And another little tip from the same article: If you’re changing careers and don’t have the relevant experience yet that would allow you to incorporate the keywords, you can include an “objective” that includes a list of skills you want to develop. That way, your resume will come up in keyword searches.

How One Company Is Using Wikis and Blogs to Unclog E-mail Boxes

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.

Top 30 offshore locations

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

Primer: Ajax

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.