1 2 3 4 5 6 Previous Next

Articles

89 Posts tagged with the compliance tag
| More
246 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy

Technology On Tap

Posted by Tom Parish Nov 1, 2005

by Steve Ulfelder

 

An Executive Guide to Utility Computing -- What it is, what it isn't,  and the kind of results you really can expect

 

In the May 2003 issue of the Harvard Business Review, Nicholas G. Carr wrote  a provocative article titled "IT Doesn't Matter". As might be expected, it roiled the zone in which business and IT collide; the article immediately spurred counterpoint columns, became the subject of dozens of symposia and launched heated boardroom discussion.

 

A careful reading of Carr makes it clear that his true argument is not so much that IT doesn't matter, but that it matters so much -- has become such a slab of business bedrock -- that it is actually IT's competitive value that's no longer a potential business differentiator. This is highly arguable itself, of course; some might say that in today's business environment, technology doesn't matter in the same fashion that electricity and running water don't matter.

 

Which brings us to the concept of expecting technology to behave as electricity and running water do. Those commodities are available anytime they're needed; they stand by invisibly when they're not; the infrastructure that surrounds them is resoundingly reliable; and they are paid for based on consumption.

 

This "invisible utility" model is the promise of on-demand computing, which also is referred to as flexible computing, grid computing, autonomic computing and a host of other terms. (Editor's note: After studying these terms, we've decided "on-demand computing" is both a good description of the practice and a name commonly used in the industry.

 

The dizzying variety of names is a symptom of the wider confusion surrounding on-demand computing. The field is growing so quickly and is being "spun" so furiously by vendors, system integrators, analyst firms and other interested parties that business executives seeking to learn about and evaluate it have a difficult time getting a solid footing. "Different suppliers are offering different mixes of [hardware, software and professional services] and using the same buzzword," says Dan Kusnetzky, a research vice president at Framingham, Mass.-based IDC. "Managers are often confused."

 

IT and business leaders are taking the on-demand computing movement very seriously -- as they should -- but they are also appropriately skeptical, having seen the hype cycle at work before. Murray Horwitz, CIO at Uline Inc., a Waukegan, Ill., shipping supplies company that currently has no plans to adopt an on-demand model, speaks for many technology leaders when he says, "It's a great concept, but I don't know how you implement it, and I think [vendors and enterprises] are going to have trouble figuring out how to cost it." This article's mission is to cut through the hype, language barriers and confusion to present a cleareyed look at on-demand computing -- its genesis, potential, limitations and implications for your business.

 

Defining On-demand

Here is a simple, if circular, way to define on-demand computing: It is IT functionality on demand. At its heart, on-demand consists of two elements:

 

  • An architecture in which technology resources such as servers, storage and the network are "virtualized" and organized into pools that can in turn be allocated to end users according to business processes and policy-based service levels.
  • A demand-based delivery model that offers customers a choice of deployment and payment models for deploying the architecture. Customers pay only for the resources they use.

 

To ensure business continuity, enterprises generally possess enough IT resources to meet peak demand. During off-peak hours, a great deal of processing power, bandwidth and storage capability sits unused, contributing nothing while draining electrical power, real estate and human resources.

 

The driving question behind on-demand computing is compelling: What if businesses could buy fewer of these IT resources, pool them and reliably meet users' needs by pushing the resources wherever they were needed?

 

Frequently asked questions: Do all these resources come from our own existing IT infrastructure? Or do we let a third party own the computers, so that we simply flip a switch and watch the functionality pour out? Or are we simply reorganizing the IT resources we already own? For the purposes of this article, "on-demand computing" refers to the practice of pooling your existing IT equipment, while "utility computing" refers to buying it from an outside provider.

 

Refining On-demand

On-demand computing brings a major shift in the way enterprises think about IT challenges. For the past decade or more, the idea was to integrate -- to make disparate software applications work together.With on-demand, IT becomes a set of functions a vailable on the network. "This is an architectural change," says Jason Bloomberg, a senior analyst at Waltham, Mass., research firm ZapThink. "And software architectures have always been very difficult to understand, let alone change."

 

To devise an on-demand computing architecture, the IT organization must create what's known as an abstraction layer. This is not for the faint of heart; it's a complex, time-consuming process that must begin with an exhaustive inventory of existing IT resources, which, in and of itself, is enough to frighten off many organizations.

 

Make no mistake, integration doesn't vanish in an on-demand world -- it remains a part of the picture, but it is no longer the final goal. Bloomberg offers one helpful way to think of this transformation. Under the traditional integration view of IT, all that matters about your company's mishmash of computer systems is connecting them. To shift to on-demand, you must change the mishmash into a set of Lego building blocks. Accomplishing this won't solve all your problems -- far from it -- but it's a necessary first step.

 

The major point to remember is that we are a long way from the day when you  twist the tap and useful computing flows out.

 

Many executives wonder what on-demand will do to their investment in Web services, which are essentially a way for different software programs to communicate. Most experts say Web services will play a key role in the adoption of on-demand. The reason: The initial technical challenge is to virtualize resources -- to make them behave as if they are something they are physically not -- and it's not a stretch to say that Web services do the same for software applications. Put another way,Web services are a valuable tool in transforming the mishmash into Legos.

 

A Brief History

Like neckties, technology strategies come back into fashion if you hang on to them long enough. Veterans from the days before CIOs, when IT was the Data Processing department, may recall time-sharing. Developed at MIT during the 1950s, time-sharing became a popular way to access mainframes back when computers were as big as your shag-carpeted rec room and CPU cycles were expensive.

 

The endless boom of Moore's Law drove down the price of computing horsepower inexorably, and timesharing all but vanished. Then, in the late 1990s, the general idea made a comeback when businesses called application service providers (ASPs) appeared and attempted to rent out software applications (as opposed to actual computer processing). ASPs' pitch was that they could relieve businesses of expensive hardware purchases and IT employee salaries. This promise appealed to many smaller organizations eager to avoid up-front costs. For the most part, large enterprises weren't swayed; they already had a massive IT investment, and they were being urged to view technology as a major competitive differentiator.

 

Because ASPs tended to be startups, most failed during the Great Nasdaq Meltdown of 2000-2001. That failure sticks in the minds of some e xecutives. Michael McClaskey, CIO at Perot Systems Corp. in Plano, Texas, is bearish when it comes to on-demand computing. "I fear that just as in the ASP bust of a few years ago, users will expect commodity pricing along with significant customization of service," McClaskey says, "and the two cannot coincide in a commercially viable model." While he does not entirely dismiss the concept, McClaskey says Perot Systems won't embrace on-demand anytime soon.

 

Outsourcing, too, is hardly a new concept, and many of its goals and potential gains mirror those of on-demand: lower fixed costs, improved agility, closer alignment with strategic goals.

 

In fact, many elements of on-demand computing are already commonplace in enterprise IT. The practice is "to a large extent a financing option," points out Bruce Caldwell, an analyst at Stamford, Conn., research firm Gartner, Inc., and there's certainly nothing new about leasing or renting a server, or paying for only six processors on a 12-processor server with the option to add capacity if needed. Storage is sold by the gigabyte, mainframe power by the MIPS. Even services, such as the help desk, are contracted out and paid for by the trouble-ticket.

 

What is new, then, about on-demand? Unlike leasing and outsourcing, which are IT-organization-centric, it begins with business users' needs and works backward toward a solution.

 

Naturally (and rightfully), this is a persuasive argument for business  executives.

 

What's in it for CIOs?

For CIOs, on-demand's major draw is its ability to allow them to say, "Yes, we can do that," rather than, "Now, hold on a sec." The past decade has seen senior technologists shift from their old gatekeeper role, in which they frequently found themselves explaining why various initiatives couldn't be undertaken, to a new and welcome role as enabler. "Today, the CIO is fundamentally thinking about making IT meet the needs of the business," says ZapThink's Bloomberg. "In the past, most IT groups weren't very good at that.Well, the CIO doesn't want to be the bad guy anymore. In those C-level meetings, he wants to say, 'We have a flexible IT organization that can meet the needs of the business and do it with low risk.'"

 

According to Gartner's Caldwell, this is the factor that has CIOs from every industry intrigued by on-demand: by cutting up-front investment dramatically and offering variable operating costs, flexibility and scalability, it allows enterprises to "deploy a new system almost overnight, so you see much faster ROI," he says -- and return on investment is one of the maj or goals of enterprise IT today.

 

The Challenges

Amid all the hype regarding on-demand computing and its offshoots, it pays to take a close look at what the technology cannot do -- by itself, at any rate. For example, while on-demand may help businesses reduce their investment in IT resources, it does little to address the age-old challenge of aligning technology spending with strategic business goals. Because on demand is at its root a way to shift resources from one spot to another, its Achilles' heel is exposed when the following questions are asked:

 

  • Where is the given resource needed most?
  • How confident are we that we've answered the previous question correctly?
  • What are the risks if we answered it incorrectly?

 

On-demand computing can be very attractive. But know that, if you do it poorly, you will sometimes be under-provisioned and sometimes over-provisioned. In other words, you'll be no better off than if you had simply stuck with your old-school, overbuilt IT infrastructure. In fact, you'll be worse off, because with the old infrastructure, you were almost never under-provisioned.

 

The Marketplace

One major reason for the prominence of on-demand is that most of the world's largest technology vendors have embraced it. Hewlett-Packard, IBM, Microsoft and Sun Microsystems have all made significant investments in the initiative.

 

System integrators, too, are elbowing in. Some analysts say that if on-demand gains favor, the actual practice of system integration loses its starring role in enterprise IT -- which could place system integrators in the uncomfortable position of advising clients to undo much of the work that SIs have been advising them to do for a decade.

 

But businesses implementing on-demand will face many new challenges, and many will turn to integrators for expertise -- and indeed, much of the knowledge SIs have built around XML-based Web services and other technologies will prove valuable. Thus, according to a recent Summit Strategies report, on-demand is "a double-edged sword" for global SIs -- those firms "will certainly not be shut off from all this emerging technology," the report says, but they are "unlikely to reap huge revenue gains" from on-demand.

 

IT veterans have watched plenty of Next Big Things fizzle. In a recent IT World survey, 25 percent of all respondents called on-demand a smoke-and-mirrors technology. Uline CIO Horwitz says, "On-demand will never be as cost-effective as buying the correct size hardware and planning for peak loads. It is a great concept and could solve many issues. But most of the time as a CIO, you need to be in control of the hardware environment, and this does not lend itself to that."

 

Colin Rankine, an analyst at Cambridge, Mass.-based Forrester Research, is another skeptic -- from a value standpoint. "The pay-per-use model is intuitively appealing, but the reality is that technical and licensing issues don't allow effective resource-sharing," Rankine says. "For enterprise data centers, it's a zero-sum game; the risk and metering overhead cancel out any savings."

 

For most, merely evaluating on-demand is a challenge today, what with the rapid change and unsettled terminology that prevail in the field. However, it's a challenge

worth addressing, as on-demand may be the most significant shift in IT thinking to arise in the past 20 years.

 

Research Roundup

A LOOK AT SOME OF THE LATEST TALK AND TERMS OF ON-  DEMAND

One of the difficulties in discussing and evaluating on-demand computing is that as with most young, rapidly changing technologies, the various names and terms used to describe it are constantly in flux. For example, some use "grid computing" to refer to something quite similar to on-demand computing, while others think of grid computing as vast peer-to-peer networks of home PCs.

Confusing? You bet. "We know of no fewer than 14 buzzwords" commonly used to describe core on-demand computing alone, says Dan Kusnetzky, a research vice president at Framingham, Mass. - based IDC. We'll try to cut through the confusion and describe the types and offshoots of on-demand computing as they are most commonly used today.

On-demand computing is an enterprise computing model in which resources are funneled to users according to demand. Those resources can theoretically include servers, network bandwidth, storage, data and even software applications; moreover, they may originate with an outside service provider or within the enterprise itself.

Think of on-demand computing as the parent of many of the other terms defined here; that is, utility computing and grid computing as subsets of on-demand.

Utility computing is the on-demand subset (sometimes called pay-per-use or metered services) in which the IT resources and infrastructure are provided by an outside services firm. As the name suggests, enterprises are charged according to their usage.

Grid computing is the practice of applying many networked computers' processing power to a single problem simultaneously. It originated as a way to create a virtual supercomputer to solve complex scientific problems. Grid computing is an ingenious way to mass the power of hundreds, even thousands, of computers that would otherwise sit idle. Today, it's most frequently used in technical, scientific and academic communities; opinions are split on whether grid computing will have practical enterprise applications in the near future.

Some call grid computing "provisioning on steroids."

DCML (data center markup language): A proposed standard created by the DCML Organization aimed at describing the components running in corporate data centers. If DCML catches on, it could become an accepted metric service providers could use to charge for utility computing. EDS, Computer Associates and BMC Software are all members of the DCML Organization, but key players IBM, Microsoft and Sun have not signed on as of press time.

Virtualization, often used to describe computer servers and storage, occurs when a device is made to appear and behave as if it is something it's not. For example, a virtual storage device may actually be a pool of several devices -- but the computer's operating system treats it as a single entity.

This is an important enabling technology for on-demand because the idea is to pool multiple devices into a single virtual entity, then draw from that entity as needed.

Web services: A relatively new class of software  applications that can communicate and work with one another over the  Internet.

| More
217 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy

Securing Compliance

Posted by Tom Parish Nov 1, 2005

by Tom Field

 

Need to comply with HIPAA, Sarbanes-Oxley, Basel II or other regulatory requirements? Trying to decipher IT security's role? Be prepared for good news and bad news. The bad news: Demonstrating regulatory compliance will put IT security efforts under heightened scrutiny. The good news: This scrutiny will force enterprises to do something they should have been doing all along: Ensure that adequate security policies and procedures are in place, monitor for any lapses in compliance, and fix any problems that arise.

 

"When companies look at what they need to do to comply with these regulations, it turns out that much of it is what they should have been doing anyway to make the environment more secure," says Mark Nicolett, research analyst at Gartner. "So many of the regulations aren't really demanding anything beyond well-defined and effective identity and access management policies, practices and processes, and effective monitoring functions."

 

Rather than see regulatory compliance as a burden, smart enterprise leaders see it as an opportunity to demonstrate that investing in IT security is more than just a cost of doing business. It can pay off by helping companies reduce financial risk, maintain customer confidence, increase trust among business partners, protect the company's reputation -- and keep the auditors happy. "If you're not ready to answer auditors' questions, that's a sign you don't have your act together," says Michael Rasmussen, principal analyst in Forrester Research's security research group. "If you don't have a well-documented security architecture and someone who can answer questions, that's going to be a red flag that something requires further investigation."

 

SECURITY CHECKLIST

Top Tips on How to Secure Compliance

DEFINE:
  • Which data assets need protection -- financial information, customer  records, patient health history, etc.?
  • Who can and should access that data?
  • Retool security policies and procedures to protect assets appropriately.  Ensure protections meet regulatory requirements.

PROTECT:

  • Does technology currently in place ensure compliance with controls? What  protection gaps exist?
  • Decide whether to invest in new technology -- e.g., identity management, access control management, password management, intrusion detection -- or whether to deploy existing technologies more broadly.
  • Reevaluate protection mechanisms as new applications come online, employees, customers or partners change, or as regulations evolve.

VERIFY:

  • Automate notification to IT personnel when access breaches occur and  validate remediation processes.
  • Consider security information management systems for identifying access  violations and documenting compliance.

Seeing Security Through a Business Lens

From an IT security point of view, the first aspect of demonstrating regulatory compliance is documenting existing security policies and controls, seeing how those mesh with regulatory requirements, and making changes where necessary. Companies can take a high-level view, using the ISO 17799, CobiT or COSO security standards as a framework, but that won't get them all the way there, says Amy Ray, trustee professor of computer information systems at Bentley College in Waltham, Mass. "A high-level centralized security policy doesn't work well because systems are decentralized, and information sharing is happening outside the network," Ray says. "Much of the new legislation, including HIPAA [and the Gramm-Leach-Bliley Act], is driven by problems associated with external information sharing. This is a new phenomenon."

 

In some ways, going through this definition stage is the ultimate exercise in IT-business alignment. It's imperative that IT avoid talk of packet sniffers and buffer overflows, analysts say. "A lot of the process of documenting compliance means identifying where information is in the enterprise, what systems and business processes interact with it, and what controls are in place," Rasmussen says. "In trying to hit the technical [side of compliance], you have to go through the business lens." Ray concurs: "The onus is on security officers to speak the language of business."

 

Translating Policy Into Technology

After companies have defined security policies and procedures that meet the regulatory requirements, and have identified critical assets and business processes, the next step is to ensure that the appropriate technology is in place to protect those assets. Organizations that have focused their security efforts primarily on the perimeter -- building good fences, so to speak, to thwart external attacks -- will need to broaden their focus to police activities on internal networks and applications. "Most organizations have adequately addressed security around the perimeter, but the heart of the regulations is around specific data at the core of our networks and systems," Rasmussen says.

 

In response to regulatory compliance and audit demands, Gartner's Nicolett says he has seen an increase in client activity in two areas: User administration and access controls, and monitoring for lapses in user administration and access controls. Password management, identity management, and access-control software are garnering attention, as is software that monitors system and application logs for administrative changes and resource access.

 

Some organizations may not need to buy new technologies to comply with regulations. "It's more about documenting or more effectively managing what you have," Rasmussen says. If a company has role-based access control deployed in one part of the organization, for example, it should use that capability in another part. Rasmussen has seen companies roll out intrusion detection systems and then neglect to have anyone monitor them. "Intrusion detection doesn't make much sense if you're not going to have analysis behind it," he says. Many companies could also do a better job of making sure that new operating systems and applications are securely configured when they are installed, and have patches added when new vulnerabilities are exposed, he says.

 

Checking Compliance

When auditors come knocking, it isn't enough for a company to just show its policies of how it will comply with regulations, and then tell them about its identity and access control management practices. Auditors are looking for a process to monitor problems -- and a process to fix them. Security information management systems, which aggregate log data from security devices, network devices and applications, can help companies show that they can find lapses in compliance. Such products also offer real-time event management, as well as security analytics and reporting.

 

One cautionary note: Auditors' requirements for monitoring will probably get more specific, according to one expert, as they learn more about what types of technology-fueled capabilities companies can deliver.

 

Security Slip-ups: What's at Stake

HIPAA, SOX, European data privacy laws and opt-in email laws, among other regulations, all have penalties attached to them for noncompliance. For example, in Italy, commercial spamming has become a crime punishable by fines of up to 90,000 euros and jail time. U.S. regulators have shown that they are not afraid to go after companies on security-related violations. In April 2004, after the Federal Trade Commission alleged that a security flaw on TowerRecords.com exposed customers' personal information, violating federal law and the Website's privacy policy, Tower Direct signed a consent decree agreeing to have its Website security audited by an outside firm every two years for the next decade. Just over a week later, in response to the New York Attorney General's office investigation of a vulnerability on BarnesandNoble.com that could permit unauthorized access to customer accounts, the online bookseller agreed to establish an information security effort, set up programs for management oversight and employee training, hire an external auditor, and pay additional costs and penalties.

 

Even in the face of these cautionary tales, some companies may be tempted to do the minimal amount of work possible to comply with regulations. But experts say companies would be better served by taking a proactive approach. "Minimal compliance with legislation is not a strategic investment," says Bentley's Ray. "The challenge for security personnel in all companies is to demonstrate how security investments can yield return through reduction of financial risk, maintenance of customer confidence or other business metrics. But it is going to require a shift in thinking for those security officers, as well as some extra work to develop and monitor metrics on return on security investment."

| More
204 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
| More
214 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
| More
224 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
by Brenda M. Michelson
Reprinted with permission from the Patricia Seybold Group

It's a Service-Oriented World

It's no secret that we are fans of services and service-oriented architecture. For years, we have been proclaiming the significance of service -- oriented architecture and Web Services technology in creating an adaptive IT architecture for customer experience.

 

More recently, we have shared our belief that the current uses of SOA for integration and customer- (user-) facing applications are merely the first stages of the service-oriented evolution. Over the next few years, SOA will be the springboard for innovative IT shops to move towards business scenario development. In business scenario development, IT business solutions will be compositions of services, business events, and business processes. These compositions match the interactions of your business -- with customers, partners, employees, and regulatory agencies -- in support of commerce, collaboration, and information exchange.

 

Now, everyone is talking SOA, services and Web Services. If you Google "service oriented architecture," you get almost 12 million hits. 12 million hits for an IT concept with "architecture" in it! And if you Google "Web Services," over a billion hits! While that's no indication of true adoption, it certainly does validate the buzz factor.

 

In fact, so many people are talking SOA, and labeling their products and services accordingly, OASIS has recently formed an SOA reference model technical committee. According to the May 3, 2005, OASIS news release1, "the SOA reference model will offer an understanding of the core elements within a service oriented environment and the associations and relationships among those elements." Essentially, the intent of the reference model is to separate fact from fiction -- to provide software and application architects a starting point to delivering SOA solutions. This is good, but as we all know, it will take time (perhaps a lot) to complete.

 

In the meantime, as a service to our clients who are interested in, or are pursuing a service-oriented strategy, we have developed this overview report on services and SOA. This "SOA Cheat Sheet" report includes key service concepts, information on supporting technologies, a view of the SOA landscape, and some keys to SOA success.

 

Service and SOA Basics

What Is a Service?

Simply stated, a service is a thing that fulfills a purpose. A service is, in essence, a "worker," employed to achieve a specific end goal for a requester. The end goal may be small in scope, such as retrieving information, or large in scope, such as executing a business process. Most services are in the middle, completing a function. The scope of a service is referred to as its grain, or level of granularity.

 

WHAT KIND OF THING IS A SERVICE? A service is an abstract resource that has a name, a job, job tasks, contact information and policies regarding security and service levels. To use (request) a service, you send a message -- in accordance to the contact information and policies -- and then (if appropriate), receive a reply message.

 

A SERVICE'S JOB. The job of a service is limited to a single distinct business concept, function, or process. This characteristic is referred to as the bounds of a service. Finding the correct bounds is a key factor in service definition. A service may call upon other services if it needs assistance to complete its job. This service-to-service relationship is called collaboration.

 

The term SOA is used interchangeably for three distinct concepts: the architectural concept, the style of the resulting business solutions, and the supporting infrastructure.

SERVICE COLLABORATION. Services collaborate through  orchestration, business interaction, or interception:

 

  • Orchestration is a type of collaboration in which the primary service directly invokes other services. The primary service knows the sequence of actions and the interfaces, responses, and return states of the called services.
  • Business Interaction is a type of collaboration in which some coordination mechanism knows the sequence of actions, possible states, and paths of interaction among one or more services. The business interaction is usually long-lived involving requests/messages from multiple parties. The coordination mechanism may be a business process execution engine, a workflow engine, an event handler, or an enterprise service bus.
  • Interception is a type of collaboration in which an intermediary service receives and acts on a request (or reply) and then forwards the request (or reply) to the original target. Interception is used to perform common functions such as security, policy, audit, and translation. In many interception scenarios, the requesting and providing parties are unaware of the intermediary service.

 

NOT ALL SERVICES ARE ALIKE. Not all services are simple information-oriented requests/replies. Beyond request/reply, a service may be a worker, a monitor, an agent, an aggregator, or even a process

.

  • Request/Reply is an information-bearing service. The service either retrieves information and/or performs a calculation/manipulation on behalf of the requester to produce a result. The Request/Reply may perform information update tasks, but it often calls upon a worker to add, change, or delete information.
  • Worker performs a function, most likely changing the state  of the thing it works on.
  • Monitor is a service whose job it is to observe something  and report on its findings based on monitoring and notification rules.
  • Agent is a service whose job it is to observe something and then act on its findings. An Agent shares behavior with a Monitor in that it observes based on monitoring rules, however an Agent differs from a Monitor in that it may take action(s) based on its findings.
  • Intermediary is a service that intercepts a service request (or reply), performs a value-added function (usually translation or policy), and then forwards the enhanced message to the original target.
  • Aggregator is a service that combines results from federated sources or services. A Request/Reply service may use the Aggregator. Aggregator services will play a role in right-time architecture, business activity monitoring (BAM), and the Grid.
  • Process is a long-running service, coordinating the actions of multiple parties through a series of work steps. The work step activities may also be services.

 

What Is SOA?

The term SOA is used interchangeably for three distinct concepts: the architectural concept, the style of the resulting business solutions, and the supporting infrastructure. In this section, we describe each concept.

 

SERVICE-ORIENTATION. Service orientation is an architectural concept that refers to the loose coupling of a service (an abstract resource with a defined job) and its provider (the physical asset(s) that perform the job tasks). A requestor only knows what the service's job is and how to request it. The service is the only one that knows its implementation.

 

Typically, service-orientation is applied to functional assets that correspond to business concepts (Open Customer Account) or system concepts (Authenticate User). However, service-oriented thinking can apply to any domain, including integration, network, platform, or even programming services. If a requester knows what a service offers (job, service levels) and how to use it (contact, security), then it really is not important (to the requester) how that service works, as long as the results meet expectations.

 

SERVICE-ORIENTED ARCHITECTURE. SOA is an IT architecture strategy for business solution (and infrastructure solution) delivery based on the concept of service-orientation.


The two primary styles of SOA used in business solution development are  composite application development and flow.

SOA STYLES FOR BUSINESS SOLUTIONS. The two primary styles of  SOA used in business solution development are composite application development  and flow.

 

Composite Application Development. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one business domain. Composite applications are often delivered in a portal.

 

Flow. In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise.

 

  • Business Process-Driven. In business processdriven architecture, the flow of work, as a series of activities, drives the requisite application and human behavior to complete a business transaction or process. The process is typically long running in nature, involving multiple parties and/or applications within an enterprise or across enterprises.
  • In business process-driven SOA, a business process may implement as a service, and/or a business process step (activity) may invoke one or more services.

  • Event-Driven. In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The interested parties then take action. The eventdriven action may include the invocation of a service (thus event-driven SOA) or the triggering of a business process or workflow.

 

Closing the loop on flow, any service may generate an event or be invoked via an automated transaction (business process step, eventdriven activity). We believe this is the true power of SOA, combining services, events, and business process for human and automated (agent-based) interactions.

 

SOA ENVIRONMENT. Refers to the collective environment that allows services to be defined, developed and used by other services, and to be assembled into solutions by adding process, interaction mechanisms, user interface, and/or rules. In addition to service development and solution assembly, the SOA environment provides runtime and management functions such as service discovery, policy definition and enforcement, quality of service (performance, availability, reliability and load), transaction management, audit, and usage metering.

 

Why SOA?

Certainly, everyone is talking about SOA, but talk doesn't justify adoption. In our experience, we find that SOA has both business and IT advantages.

Business advantages consist of the following:

 

  • Consistent Experience. An SOA can provide a consistent  experience for customers and partners across channels and lines of business.
  • Business Agility. An SOA can add new functionality, expose functionality to new channels, and vary functionality based on context (customer, partner, entry point).
  • Mix and Match. An SOA can compose business solutions from a  reusable service collection, leveraging internal and external services.
  • Optimize Interactions. An SOA can optimize business interactions for customers, partners, and internal constituents through the implementation of business scenarios (process, events, and services) versus traditional applications.

 

IT advantages include:

 

  • Reduction of Costs. Reuse of services reduces IT  development and maintenance time and costs.2
  • Leverage Existing IT Investments. Your service providers are existing code (objects, components, legacy modules, and application package APIs) and information assets (databases, files, and documents).
  • Transition Strategies. An SOA can provide application and  portfolio transition strategies.

 

References

1 See http://www.oasis-open.org/news/oasis_news_05_03_05.php.

 

2 Note that the ROI from reuse typically occurs between the second and third use of the service. This note is based on industry metrics that consider the increased design and development time to "get the service right" to be reusable.

 

--

 

Brenda M.  Michelson is the Sr. VP and Sr. Consultant for the Patricia Seybold  Group.

 

Read more reports on Web Services and  Service-Oriented Architecture by Brenda M. Michelson and  others.

| More
334 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
| More
288 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
| More
227 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy

Money Matters

Posted by Tom Parish Nov 1, 2005
by Debby Young

The Importance of Justifying IT Projects in Financial  Terms

 

After several years of fighting for every dollar while being challenged to do more with less, IT executives are seeing signs of a shift in expectations for IT spending. "CIOs are approaching the coming year with marching orders to do more, and to do it more quickly," observes Gary Beach, group publisher of CIO magazine.

 

Those in the trenches -- such as Kevin Johnson, founder and CTO of Seamless Technologies Inc., Morristown, N.J. -- find that the push for speed and results forces CIOs to raise the bar on virtually every IT initiative. Says Johnson: "Technology executives today know they must get to positive value in less than a year."

 

If you'd like to achieve that kind of result, you need only look to world-class companies for inspiration. Top performers consistently demonstrate that even during lean years, if you choose your IT initiatives wisely, you'll spend less than your competitors while still gaining share in your market.

 

According to new research from the Hackett Group, an Atlanta-based division of the consulting firm Answerthink Inc., total IT budgets tightened by nearly 11 percent between 2002 and 2004. Yet top-performing companies spent almost 18 percent less on per-user IT costs than did their mid-tier counterparts. They also employed 37 percent fewer IT staffers.

 

How did they do it? Beth Hayes, the Hackett Group's IT practice leader, cites several ways that world-class performers maintain their lead, including:

 

  • Pushing hard on their internal IT staff to be as efficient as possible
  • Simplifying their IT infrastructures to remove excessive cost and headcount
  • Adhering to common standards and methods to keep projects on time and on  budget

 

However, the biggest factor in achieving world-class status is a familiar one: The need to align IT with business. It's a matter of understanding both the business goals and the IT controls that must be in place to support them, and demonstrating how new IT initiatives contribute solid business value to day-to-day operations.

 

Though an October 2004 CIO poll of IT executives indicates optimism that spending will grow in the coming year, financial justification continues to be paramount in getting the go-ahead from investors. Financial executives still remain reluctant to green-light IT projects without solid evidence of real business benefits.

 

In other words, to get your IT project funded, you must "sell" your case to the people with the checkbooks. Doing so effectively requires making sure your metrics jibe with the way financial decision-makers like to see project costs justified. While you don't need an MBA or a Ph.D. in finance to calculate costs and benefits, it does help to understand what CFOs want. Of course, even some of the most worthy IT projects ultimately won't receive funding, but framing your business case the right way may well increase your chances for success.

 

Components of an Effective Business Case

A well-structured business case should open with a compelling executive summary that argues for funding by presenting relevant facts about anticipated business benefits. It should also explain why the project is being proposed now, what problems it will solve, its specific financial impact on the company, and the timeline for spending and return on investment.

 

The rest of the business case should provide detailed validation of your argument by describing the problem, solution, project goals, and metrics. Following are tips on addressing each of those issues.

 

PROBLEM DESCRIPTION. What are the issues (and, if applicable, the opportunities) that this initiative will address? Clarify the compelling need for change. Highlight other organizations' best practices for addressing similar situations. Then present the gap analysis between where your company is today and where it should be.

 

SOLUTION DESCRIPTION. How do you propose to address the problems identified? Provide a concise overview of the technologies and business process changes involved, as well as major issues affecting other departments. Describe the resources and costs required for implementing the solution. Cite any alternatives you've considered, explaining why they were rejected. Present a project timeline, including key milestones. Finally, lay out the financial risks and their potential impact on the business.

 

KEY GOALS AND METRICS. What exactly do you want the project to accomplish? How will you measure its success? Define the goals and the metrics that will be used to ensure alignment between the IT solution and the business issues it is intended to address.

 

Different Ways to View the Financial Impact

A successful business case translates the proposed solution into the universal language of money. But make sure that your financial analysis matches the standards used by the financial executives who will sign off on your project.

 

Here are some of the ways in which you might paint the financial picture.

 

DISCOUNTED CASH FLOW ANALYSIS (DCF) evaluates the movement of cash in and out of your organization over time, taking into account the value of money over time. The two most widely used methods are net present value (NPV) and internal rate of return (IRR). NPV compares the value of money spent today against the value of benefits that will occur in the future, taking into account the firm's cost of capital (discount rate). The discount rate is calculated based on the firm's weighted average cost of capital, which varies by industry segment and financial strategies. IRR is the interest rate that equates the initial investment outlay with the present value of future cash inflows (cost savings) over a period of time, usually three to five years.

 

The core of a discounted cash flow-based financial decision model is the cash-flow table. A simple table that shows costs and benefits discounted to today's dollars allows financial decision makers to compare different proposed capital projects such as data center consolidation or an application upgrade.

 

RETURN ON INVESTMENT (ROI) is a ratio consisting of the NPV of benefits (cash inflows) minus the NPV of costs (cash outlays) over the NPV of costs (cash outlays).

 

TOTAL ECONOMIC IMPACT (TEI), as presented by Forrester Research Inc., of Cambridge, Mass., is a highly regarded methodology for calculating financial impact. It builds on the basics included in a discounted cash-flow analysis by including project costs and benefits. But it also factors in solution flexibility and project risk. Costs and benefits are discounted to today's dollar, the same as with ROI. Flexibility focuses on how the project will enable the deployment of future projects that will have a positive financial impact on the company. Risks require discounted costs and benefits to provide a range of less-than-optimal results. Risk-adjusted ROI adjusts all project costs higher and financial benefits lower to provide a more conservative view of the technology project's overall value.

 

Validate Baseline Data to Ensure the Integrity of Your Business Case

To ensure that all your calculations lead to credible results, establish a standard process to collect data scattered across the enterprise. Identify people in each department or business unit who can ferret out the necessary information. Then arm them with a carefully constructed questionnaire designed to collect the critical metrics in a uniform way that guarantees the integrity of your business-case calculations.

 

Also, consider benchmarking the metrics from your business units against industry standards. For instance, a number of third-party research firms -- including Forrester, Gartner Inc., and the Help Desk Institute (HDI) -- conduct technology studies spanning a range of industry segments. You can compare your in-house information against the researchers' findings to help create your own unique baseline.

 

Building a Case Around Reduced Headcount

Recently a leisure/travel/entertainment conglomerate hoping to reduce its overall employee headcount began considering the possibility of consolidating its service desk. Framing the financial justification for that effort was quite straightforward: Implementing the consolidated service-desk platform and single-data model would pay off quickly by reducing the need for parallel support and development staff to service multiple platforms.

 

But the company went one step further by seeking additional potential sources  of ROI, digging for specific metrics such as:

 

  • Dollar savings from retiring the maintenance stream from one platform,  including software and hardware licensing expenses
  • The company's per-minute costs for system outages
  • Financial impact differentials between applications serving external  customers and those supporting internal staff

 

The company's business case, developed using Forrester's TEI model, also incorporated long-term cost-avoidance savings. Those benefits included:

 

  • The need for fewer hardware and software licenses
  • A reduction in outages impacting revenue streams
  • Faster problem resolution, thus requiring fewer support resources

 

While making a case for long-term ROI isn't overly difficult, it's worth noting that CIOs are under pressure to demonstrate greater returns in shorter time periods. As the entertainment conglomerate's experience indicates, today's most compelling business cases focus first on a proposed IT project's short-term returns, then with projected longer-term benefits.

 

The biggest challenge in building any business case is obtaining reliable and accurate baseline data. But applying a flexible financial model -- such as Forrester's TEI methodology -- can make that task easier.

 

In addition, using risk-adjusted ROI with both aggressive and conservative cost and benefit assumptions lets stakeholders see the range of hard-dollar costs and savings that might result from a proposed IT project's implementation.

| More
309 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy

Four Traps

Posted by Tom Parish Nov 1, 2005
by Steve Ulfelder

The biggest obstacles between you and alignment -- and how to avoid  them

 

The catalog of best practices grows daily as enterprises seek to align IT resources and processes to directly support critical business objectives. So, too, does the catalog of potential hurdles faced by those pursuing alignment.

 

Indeed, a recent survey of 200 IT executives by Deloitte Consulting and IDG Research Services found that 96 percent anticipated a positive bottom-line impact if they could improve alignment -- but only 10 percent could claim their alignment efforts were extremely successful.

 

Here, we've identified four major alignment traps and provided expert advice  on how you can avoid or overcome them.

 

Trap 1: The Great Wall

Analysts say that when many enterprises begin exploring business-IT alignment, they run into a chicken-and-egg problem: They need alignment largely because, metaphorically speaking, IT and business are working on opposite sides of a high wall, with both tossing needs, demands, and blame back and forth. While alignment is clearly necessary, the biggest obstacle may indeed be that seemingly insurmountable wall itself. So any serious initiative must start with tearing it down.

 

Tim Buckley, CIO at the Vanguard Group, an investment management business based in Valley Forge, Pennsylvania, has advice worth listening to -- the investment giant was well ahead of the curve, beginning its alignment initiative in 1992. "Even then, it was clear that IT would be a differentiator for us," Buckley says. "Now, 80 percent of our business comes through our Web site."

 

Vanguard's approach to breaking down the barriers to alignment was extremely innovative more than a decade ago, and is still rare today: The company reorganized its systems development around the departments and business units that ultimately used the technology while consolidating all infrastructure operations. That meant creating one development group for the company's institutional retirement business, one for retail, and so on. "There are huge advantages to this," Buckley says. For starters, such a system "ensures that IT people need to understand only a single client -- and since we insist that IT employees know their client's business inside and out, one client is plenty."

 

Moreover, Vanguard found that the increased autonomy allowed various business groups to react more quickly to unique market pressures. Over the past decade, IT has been advised to decentralize -- or recentralize -- so many times that CIOs can be forgiven if they have a case of whiplash. But the experiences of Vanguard and other leading enterprises make a powerful argument for IT organizations that revolve around individual lines of business.

 

Trap 2: New Strategies, Old Tactics

Enterprises seeking to align business and IT often get deep into the process before realizing that they need to adjust their approach to metrics. They must, for example, expand their concept of traditional service-level agreements (SLAs), which focus primarily on technology, to include measuring service from an end-user perspective. According to Lee Adams, of the Hospital Corporation of America (HCA), a crucial challenge involves changing the IT mind-set from being focused on components to being focused on business services. Technologists are accustomed to tracking network outages, latency times, and server availability, but the idea of measuring the end-to-end quality of, say, a customer's online care-center query is new territory. HCA has addressed this by devising its own state-of-the-art metrics for measuring and understanding client experiences in real time.

 

Trap 3: A Failure to Communicate

Once an enterprise commits itself to alignment, IT must communicate to both senior executives and end users that the company has embarked on the journey, and that while impressive benefits will be seen quickly, everyone should take and communicate a long-term view across business and IT lines. This can be problematic in IT organizations that have historically not communicated well.

 

As a Forrester Research report puts it: "It is characteristic of IT shops that are considered not aligned to have a poor track record regarding communication of IT's successes and capabilities to the business." In contrast, researchers say that in aligned organizations, CIOs not only communicate in business terms -- a prerequisite in today's world -- but can "see things from the business perspective and recommend technology-based innovations that make a material difference to the bottom line."

 

When undertaking an effort as challenging and broad as alignment, IT groups don't stand a chance without the enthusiastic support of top management. Vanguard's Buckley says business managers' support was a key reason for the company's alignment success. "Starting with the CEO, all our business leaders get it," he says. "They've always been strong advocates of IT."

 

That buy-in is critical, but Vanguard's efforts are not limited to the boardroom. The company stresses two-way communication of business and technology issues at all levels. Indeed, Buckley is proud that during especially busy periods, IT employees routinely help staff the customer care center. "We spent thousands of hours doing that last year," he says. On the front lines, IT workers learn what it's like to use the applications they've created, and gain an appreciation of operations. "It's amazing the ideas that come out of that process," he adds.

 

Does a commitment to aligning business priorities and technology use bring fresh challenges to the IT organization and the enterprise as a whole? Sure. But as Vanguard's experience shows, companies are finding creative ways to meet those challenges.

 

Trap 4: Focusing on Technology or Process

An easy trap is to concentrate too much on either process or technology, rather than to develop them in tandem. Like a football team, you need to have a good defense and a good offense to win championships. A coach who concentrates too much on one at the expense of the other will win nothing. Purists would say that the process comes first, but what is the point of developing a process that creates more manual activities? Can you imagine the reaction of a business manager asked by IT to perform some manual activities as part of business alignment?

 

"Whether following ITIL [IT Information Library] principles or not, IT organizations must develop processes that are efficient, have minimum human intervention, and are cost-effective and reliable," says industry luminary and author Malcolm Fry. "This can only be achieved by focusing on process and technology at the same time. Remember that, to achieve business alignment, we have to align IT processes with the business processes, and often, technology is the only way to successfully integrate and align these processes."

| More
250 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy

The Return of Innovation

Posted by Tom Parish Nov 1, 2005
by Steve Ulfelder
| More
275 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
| More
273 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy

by Elizabeth Ferrarini

| More
259 Views 0 Comments 0 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
| More
514 Views 0 Comments 1 References Permalink Tags: article, best_practices, compliance, governance, innovation, it_management, itil, open_source, security, strategy
1 2 3 4 5 6 Previous Next

Actions