Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts

November 8, 2013

Cloud Kool-Aid

We've all drunk the Kool-Aid and believe in using the cloud.

And with almost 1 million active apps alone in the Apple Store it is no wonder why.

The cloud can create amazing opportunities for shared services and cost efficiencies.

The problem is that many are using the cloud at the edge.

They are taking the cloud to mean that they in government are simply service brokers, rather than accountable service providers.

In the service broker model, CIOs and leaders look for the best, cost effective service to use.

However, in NOT recognizing that they are the ultimate service providers for their customers, they are trying to outsource accountability and effectiveness.

Take for example, the recent failures of Healthcare.gov, there were at least 55 major contractors involved, but no major end-to-end testing done by HHS.

We can't outsource accountability--even though the cloud and outsourcing is tempting many to do just that.

Secretary Sebelius has said that the buck stops with her, but in the 3 1/2 years leading up to the rollout relied on the big technology cloud in the sky to provide the solution.

Moreover, while Sebelius as the business owner is talking responsibility for the mission failures of the site, isn't it the CIO who should be addressing the technology issues as well?

IT contractors and cloud providers play a vital role in helping the government develop and maintain our technology, but at the end of the day, we in the government are responsible to our mission users.

The relationship is one of partners in problem solving and IT product and service provision, rather than service brokers moving data from one cloud provider to the next, where a buck can simply be saved regardless of whether mission results, stability and security are at risk.

In fact, Bloomberg BusinessWeek outlines the 3 successful principles used in the creation of consumerfinance.gov by the new CFPB, and it includes: "Have in-house strategy, design, and tech"!

Some in government say we cannot attract good IT people.

Maybe true, if we continue to freeze salaries, cut benefits, furlough employees, and take away the zest and responsibility for technology solutions from our own very talented technologists.

Government must be a place where we can attract technology talent, so we can identify requirements with our customers, work with partners on solutions, and tailors COTS, GOTS, open source solutions and cloud services to our mission needs.

When Sebelius was asked on The Hill about whether Healthcare.gov crashed, she said it never crashed, which was technically incorrect as the site was down.

The cloud is great source for IT provision, but the pendulum is swinging too far and fast, and it will by necessity come back towards the center, where it belongs as an opportunity, not a compliance mandate.

Hopefully, this will happen before too many CIOs gut the technology know-how they do have and the accountability they should provide.

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

April 25, 2011

Turning IT From Frenemy to Friend

Fast Company (December 2008) describes Frenemies as a "thrilling intricate dance" of friend-enemy relationships.

Half a year later, CBS News (July 2009) reports that this words is added to the dictionary: "Frenemy--someone who pretends to be a friend, but is really an enemy."

Recently, I've heard the term applied to Information Technology, as in they they here to help (i.e. friend-like), but boy are they often an obstacle as well (i.e. enemy-like).

Obviously not the message any IT executive wants to hear about their folk's customer service and delivery!

Today, the Wall Street Journal (25 April 2011) writes about the "discontent with the [IT] status quo" and it calls somewhat drastically to "Get IT out of the IT department."

Why?

Based on responses from business and IT leaders, here are some of the key reasons:

- "IT is seen as overly bureaucratic and control-oriented" (51% business and 37% IT)
- "IT doesn't deliver on time" (44% business and 49% IT)
- "IT products and services doesn't meet the needs of the business" (39% business and 29% IT)
- "IT consists of technologists, not business leaders" (60% business and 46% IT)

Therefore, the WSJ states "both for competitive and technological reasons...business unit leaders need to start assuming more control over the IT assets that fuel their individual businesses."

This is being called "Innovative IT"--where "IT shifts to more of a support role. IT empowers business unit self-sufficiency by providing education, coaching, tools, and rules, which allow for individuals to meet their needs in a way that protects the overall need of the enterprise."

The result is rather than delivering IT to the business, we deliver IT "through the business."

In this model, there is an emphasis on partnership between the business and IT, where:

- IT provides services to the business (i.e. through a service-oriented architecture of capabilities)--systems, applications, products, tools, infrastructure, planning, governance, security, and more.
- The business exploits these services as needed, and they innovate by "dreaming up ideas, developing prototypes, and piloting changes" that will most impact on-the-ground performance.

I believe this is consistent with stage 4 (the highest) of architecture maturity--called Business Modularity--as described by Ross, Weill and Robertson in Enterprise Architecture As Strategy: In this stage, we "grant business unit managers greater discretion in the design of front-end processes, which they can individually build or buy as modules connected to core data and backend processes. In effect,managers get the freedom to bolt functionality onto the optimized core." The result is a "platform of innovation...[that] enables local experiments, and the best ones spread throughout the company."

Related to this are interviews in the WSJ today with 3 CIOs, that all bear out this IT leadership direction:

- Frank Wander (Guardian Life Insurance)--"We have IT embedded into each business and we have a seat at the table. We're partners."
- Norm Fjeldheim (Qualcomm)--"We're structured exactly the same way Frank is. IT is embedded in the business. I'm only responsible for about half the IT budget."
- Filippo Passrini (Proctor & Gamble)--"Our business partners are people outside IT....in the past we were always in 'push' mode...now...there is a lot of 'pull'."

So one of the goals of IT and business is to transform from a relationship of frenemies to friends and genuine partners; this will leverage the strengths of each--the expertise of our technology professionals and the customer insights and agility of our business people.

Share/Save/Bookmark

November 5, 2010

Turning Consumerism Into Collaboration

I’m sure you’ve noticed that we are historically and fundamentally a consumerist society.

We spend a lot of time and money shopping and buying things—many of the things that we buy, we acknowledge that we don’t even need—just check your attic lately? :-)

Many compulsive buyers have even self-proclaimed themselves “shopaholics.”

Aside from being somewhat obsessive compulsive in the way we treat buying and owning things, we tend to be pretty wasteful in buying and throwing out things, often from individualized, single use servings—think fast food, as one example.

The result, according the Environmental Protection Agency (per WiseGeek), the average American produces 4.4 pounds of garbage a day or 1,600 pounds a year (and that doesn’t include industrial waste or commercial trash).

On the flip side of all the tossing out we do, are “hoarders” or those with the tendency to keep lots of things, often piled high in every corner of their homes and offices; there is even a show called by the same on A&E television dedicated to this.

So we shop a lot, spend a lot, buy a lot, and then consume it, hoard it, or toss it. And we do this with enormous volumes of things and in ridiculously rapid cycle times—for example, how many times a week do you find yourself in the stores buying things or then taking out the trash generated from it? (I can practically hear the lyrics of the Hefty commercial playing: ”Hefty, Hefty, Hefty—Stinky, Stinky, Stinky…”)

Overall, it’s a crazy system of conspicuous consumption driven by perceived needs for materialism, highly refined and effective marketing and advertising techniques, and people’s feelings of relative deprivation.

Yet despite these, there is movement underway to change from a society obscured by habits of personal ownership and consumption to a more healthy and balanced approach based on sharing and reuse.

And this is approach for sharing is happening not just in terms of personal consumption, but also in terms of our organizational use of technology, such as in service-oriented architectures, common and enterprise solutions, virtualization, and cloud computing.

We see change happening as a result of the huge financial deficits we have piled on individually, organizationally, and as a nation; the depletion of our vital natural resources (including concerns about our future energy supplies and other limited raw materials like precious metals etc.); and the fear of pollution and the poisoning our planet for future generations.

An interesting article in Wired called “Other Peoples Property” (Sept. 2010) talks about how we are moving finally toward a model of sharing through peer-to-peer renting sites like at www.zilok.com (with 150,000 items listed including cars, vacations, tools, electronics, cloths, and more) and other swapping sites for books, CDs, video games, etc. like www.swaptree.com. Of course, Zipcars and property timeshares are other fashionable examples of this new way of thinking!

Further, the article references a new book by Rachel Botsman called “What’s Mine is Yours: The Rise of Collaborative Consumption,” about how we are moving to a new consumption model that emphasizes “usefulness over ownership, community over selfishness, and sustainability over novelty.”

With new technologies and tools there is more opportunity than ever to share and reuse, for example:

  • Online repositories of goods and advanced search capabilities provides the ability to find exactly what we are looking for.
  • Embedding everyday items with microprocessors, networking them, and aiding them with geolocation, enables us to get self-status on their presence, health and availability for use.
  • E-commerce, electronic payment, and overnight shipping, gives us the ability to have the items available when and where we need them, and we can then return them for someone else to take their turn to use them.

If we can get over the stigma of sharing and reuse, perhaps, the day is coming when we can think of many non-personal items more in terms of community use and less in terms of mine and yours, and we’ll all be the richer for it.


Share/Save/Bookmark

February 21, 2010

Common Language for Enterprise Architecture

What happens when one set of enterprise architects can’t read another’s enterprise architecture “artifacts”?

This may sound ridiculous, but this is a very real problem at the Department of Defense (DoD) and at many other agencies.

Government Computer News, 1 February 2010, has an article on “Primitives and the Future of SOA” about how “DoD looks to develop a common vocabulary to improve system design.”

Dennis Wisnosky, the chief technical officer at the DoD Business Transformation Agency came face-to-face with this problem:

“We were building a business enterprise architecture when the whole team changed because the contract [that the work was being performed under] was won by different people…The new company came in and, all of a sudden, their people had different ideas for how the architecture should be built…Their way might have been a good way, but we had already invested hundreds of millions of dollars in another way, and it seemed to be a wiser course of business action to get these new people to learn the old way.”

Mr. Wisnosky tackled the problem head-on:

Like the periodic table of 117 core elements that make up everything in our world, Mr. Wisnosky set out to build the DoD architecture using a set of primitives or basic building blocks. “Primitives are a standard set of viewing elements and associated symbols” based in DoD’s case on the Business Process Modeling Notation (BPMN)”—a graphical representation for processes in a workflow. Armed with the set of primitives, DoD was able to get “the business process architecture, so that they are described in a way that the meaning of this architecture…is absolutely clear to everyone.”

Wisnosky aptly compared using a common language (or set of primitives) for EA, so everyone could read and understand it, regardless of their particular EA methodology to how musicians anywhere in the world can read standard music notation and similarly how electrical engineers can read electrical diagrams based on standards symbols.

This is a big step for EA, where traditional architecture artifacts are not as user-centric as they should be and often leave their readers/audience questioning the purpose and message intended. In contrast, the use of a common EA vocabulary and set of symbols is right in line with developing a user-centric enterprise architecture that is easy for users to understand and apply, because once you know the standard set of primitives you can read and understand the architecture better than an architecture based on a proprietary or ever changing vocabulary.

As Wisnosky points out, primitives are also a nice fit with Service Oriented Architecture, because you can use primitives or patterns of primitives to represent standard business processes and these can be used over and over again for the same services that are needed throughout the business.

This use of primitives for business process notation is consistent with the use of the National Information Exchange Model (NIEM) for information notation. “NIEM enables information sharing, focusing on information exchanged among organizations as part of their current or intended business practices. The NIEM exchange development methodology results in a common semantic understanding among participating organizations and data formatted in a semantically consistent manner. NIEM will standardize content (actual data exchange standards), provide tools, and managed processes.”

While, we need to leave a certain amount of flexibility in EA for architects to apply their trade to meet specific agency requirements, there is a huge benefit to standardizing on a common vocabulary, so architects can speak the same language. This concept is all the better when the language and design methodology selected for EA is simple and clear so that even non-EA’s (our regular business and IT people) can read and understand the architecture.

Building EA with primitives and clear and simple vocabulary and design represents a user-centric EA moment that I for one, applaud loudly. Another way to say this is that an EA without primitives is a primitive EA.


Share/Save/Bookmark

September 5, 2008

The Future of Cloud Computing

Cloud computing—“a style of computing where IT-related capabilities are provided ‘as a service’, allowing users to access technology-enabled services ‘in the cloud’ without knowledge of, expertise with, or control over the technology infrastructure that supports them.” (Wikipedia)

In an article in InfoWorld, 7 April 2008, called What Cloud Computing Really Means, Galen Gruman states that “Cloud computing encompasses any subscription-based or pay-per use service that, in real time over the Internet, extends IT capabilities.”

What’s an example of cloud computing?

An example of cloud computing is Google Apps that provides common business applications (similar to traditional office suits) online.”

How does cloud computing work?

In cloud computing, resources--either hardware or software--are available on-demand—as needed.

In the case of on-demand software, application service providers (ASPs) offer software as a service (SaaS). And for on-demand hardware or IT infrastructure (i.e. virtual data center capabilities such as servers or storage), the offering takes the form of utility computing. In both cases, technology resources are served up on a pay-as-you-go or metered basis, similar to the way a public utility would charge for electricity, oil/gas, telephone, water, and so on.

The cloud computing model is similar to service oriented architecture where there is a service provider and consumer, and here the Internet functions the basic service broker.

Cloud computing is has a basis in technology virtualization in which service providers "hide the physical characteristics of computing resources from their users [consumers]." (Wikipedia)

What are the major advantages of cloud computing?

Cost—one of the big advantages of this computing model is that the upfront IT investment cost is little to none, since the IT assets are in essence being rented.

Scalability—customers have the ability to use more resources when they have a surge in demand and can scale back or turn off the spigot when the resources are not needed.

Flexibility—As IT capabilities get updated by the service provider, consumers in the cloud model can make immediate use of them and benefit sooner than if they had to stand up the capabilities themselves.

Mission focus—The enterprise can stay focused on core mission and mission support capabilities and in essence easily outsource business support functions, where the service provider is responsible for enabling more generic (not strategic or differentiators) business capabilities.

What are the enterprise architecture implications?

Cloud computing can play an important role in focusing IT solutions on strategic mission requirements, simplifying and standardizing our IT infrastructures by outsourcing capabilities, utilizing a services oriented architecture (SOA) model where common business services are served up by providers and consumed by the enterprise, and more effectively managing costs.

What is the future of cloud computing?

Obviously, there are security implications, but as Galen Gruman states: “as SOA and virtualization permeate the enterprise, the idea of loosely coupled services running on an agile, scalable infrastructure should make every enterprise a node in the cloud. It’s a long-running tend with a far-out horizon. But among big metatrends, cloud computing is the hardest one to argue with in the long term.


Share/Save/Bookmark

August 29, 2008

SOA Liberates Productivity

Harvard Business Review (HBR), June 2008, has a wonderful article (by Ric Merrifield, Jack Calhoun, and Dennis Stevens) on how SOA is “the next revolution in productivity.”

SOA defined:

“It is becoming possible to design many business activities as Lego-like software components that can be easily put together and taken apart…service-oriented architecture [is] a relatively new way of designing and deploying the software that supports a business activity.”

With SOA, business activities can be accessed via the Internet through web services. Rather than build proprietary, redundant business services, our organizations can re-use standardized services, developed internally or outsourced, as components that plug and play into our enterprise.

“Virtually all large companies suffer from an enormous duplication of activities; they continue to create and perform hundreds of non-core tasks that would ideally be outsourced; and they are spending exorbitant amounts on IT projects in order to support redundant and nonstrategic operations and to update core processes.”

How does this differ from other quality improvement initiatives?

Prior quality improvement efforts like Total Quality Management (TQM) and Six Sigma have focused on reducing waste and defects and eliminating unnecessary tasks and integrating disparate ones.

“For the most part, however, reengineering has involved recasting processes and the information systems that support them in a proprietary, rather than a standardized, form—that is, customized for individual organizations. Such designs make it difficult and expensive for business to share, consolidate, and change processes.”

Now with the Internet and web services, we can access standardized services that can be shared and re-used throughout disparate business units in the same enterprise and across organizations globally.

The result is business units and organizations that can simply plug and play to make use of needed services, eliminating proprietary processes and redundant systems and enabling outsourcing of noncore mission functions and activities and easier upgrades to new superior services as they come online.

What are some of the issues holding SOA back?

Firstly, many people do not truly understand SOA, what it is, what benefits are possible, and what the challenges are to doing it right.

Second, SOA is viewed by many executives as yet another hype or bubble that will cost the enterprise lots of money, but fail to provide the promised return. So, they are wading into SOA only enough to “deploy it in a limited fashion,” but without first rethinking the design of their business.” However, to really reap the benefits of SOA, organizations need to transform from “collections of proprietary operations into a collection of standard plug-and-play activities,” and this requires redesigning not only IT systems, but operations.

In designing SOA-based processes, the unit of analysis and reengineering is no longer the task (as in Frederick Taylor time and motion studies of the late nineteenth century) or the department, or even the division. “In the age of the Internet and SOA, the unit of analysis is not a company’s way of conducting its operations at all; it is the primary purpose or desired outcome of each activity no matter how that activity is accomplished.”

Where are we today with SOA implementation?

“Unfortunately, few companies are using SOA to create more productive and focused organizations or to slash costs by purging duplicative operations and technologies. They are not revisiting the fundamental design of their operations.”

To overcome the obstacles in reaching SOA enabled organizations, we need a strong dose of enterprise architecture to identify and decompose our performance outcomes we are driving toward, the business processes to achieve these, the information required to perform these, and the systems that can serve them up.

According to HBR, our business model activities can be categorized into the following for SOA implementation:

  • Primary (I would call this core mission)—those that should be kept in-house and are “top priority of programs to improve operations and technology” (i.e. through business process improvement, reengineering, and the introduction of new technology).
  • Shared—those that “can be shared with other divisions” (i.e. through common solutions).
  • Shifted—those that “can be transferred to customers, suppliers, or operational specialists” (i.e. outsourced).
  • Automated---those that can be “automated so they can be turned into web services.”

All but the primary activities are ripe for SOA-based enhancements. And according to HBR, only about 20% of activities are primary, so that leaves plenty of room for a SOA plug-and-play.

The idea is to cease defining our noncore mission processes and activities as proprietary, requiring elaborate and expensive customized solutions for these. Instead, we should use standardized “swapped, bought, or sold” services. Then, we can truly focus our business process reengineering and IT investments on our organization’s core mission activities—working to to differentiate ourselves and develop unsurpassed competitive advantage.


Share/Save/Bookmark

October 27, 2007

Service Oriented Architecture (SOA) - Defined

What is Service Oriented Architecture?


Share/Save/Bookmark

September 15, 2007

SOA – Does the Emperor Have Clothes?

Architecture and Governance Magazine, Volume 3 Issue 3, reports that one of the Top 10 Challenges in Enterprise Architecture is “Getting Ready for Service-Oriented Architecture (SOA)”.

- Why is SOA proving to be such a challenge?

The article reports that “most architects have not done much of either substance or significance in this area.” Further, “most of what enterprise architects have addressed in this space concerns aligning IT with the business and governance”—and this is something that EA has been doing all along anyway.

- So what has SOA changed?

“What has changed is the promise of abstracting services that can be reused.”

However, some have questioned SOA:

  1. Is SOA “just a revival of modular programming (1970s), event-oriented design (1980s), or interface/component-based design (1990s)”?
  2. Is SOA “just another term for Web Services”?
  3. Is SOA “merely an obvious evolution of currently well-deployed architecture (open interfaces, etc.)”? (Wikipedia)

Others have questioned if SOA and EA are even distinct disciplines?

“So, has SOA in fact evolved into EA? A to question to which the answer is yes and no." The author continues, “essentially there are three evolutionary paths:

  1. EA is absorbed by SOA
  2. SOA is absorbed by EA
  3. EA / SOA merge into a new concept”

Finally, the authors propose #3 merging EA and SOA as follows:

“SOA-A+EA = SOEA”

With the conclusion that “in order to create this holistic view EA and SOA must not be seen as separate disciplines, but to see the two as one will bring changes on such a scale that we are now talking about SOEA Service Oriented Enterprise Architecture.” (Journal of Enterprise Architecture, August 2007, Rasmus Knippel and Bo Skytte)

While the authors apparently seems to think SOA is important (although they call it "increasingly more abstract"), the relationship to EA is changing and unclear—Not sure this idea about SOEA is helpful at this juncture!

- How helpful to SOA development is the guidance from the Federal Enterprise Architecture (FEA), Service Reference Model (SRM), which talks about services and capabilities?

Not very! The SRM is supposed to “provide a high-level view of the services and capabilities that support enterprise and organizational process and applications.” (FEA, SRM). However, the service domains, service types, and capabilities listed in the FEA SRM are quite muddy, at best. Here is an example:

  • The domain of Process Automation is defined as “the set of capabilities that support the automation of process” [hasn’t every 5th grader been taught not to define a term with the same term?]
  • And it continues “and management that assists in effectively managing the business” [well that is a pretty broad definition— can’t all services assist in effectively managing the business?].
  • Then after the definition, you’re expecting some pretty extensive process automation services, but the SRM lists just 2 components:
  1. Tracking and Workflow (which includes capabilities like case management [what’s that doing here?] and conflict resolution [isn’t that a leadership skill set?])
  2. Routing and Scheduling, which includes just Inbound and Outbound Correspondence Management [so where the scheduling piece like calendaring or time management that one normally associates with scheduling and how does the routing as in Routing and Scheduling reflect the routing inherent in Tracking and Workflow category above—seems like some category overlap]

I’ll let you look at the SRM yourself to see evaluate the clarity of the other categories, but they are pretty much the same. Ok, I can’t resist, here’s one more:

  • The domain called Business Management Services, after the domain of Process Automation, actually has a service type in it called management of process {why isn’t this in the process automation domain?].
  • The other service types in this domain include Organizational Management [that includes workgroup/groupware and network management, huh?]
  • And Investment Management [ok]
  • And Supply Chain Management [which includes things like procurement, Warehousing, and Inventory Management— so why isn’t this part of back office services, like Finance, Human Capital, and Asset/Material Management?]

If this looks confusing, you’ve got my point, it’s because the FEA SRM is confusing.

- So what’s an enterprise architect to do?

Architecture and Governance Magazine says, enterprise architects need to take back the high ground here—and that must be done in 2007…today’s enterprise architect must re-engage with all the principals in the enterprise by making a case for seeing service and technology architectures as one.”— this is good advice, I suppose, but also more than a little vague!

I’ve seen a bunch of presentations (including a recent one from Department of Education) where EA has tied IT services (pretty much their IT portfolio) to requested business capabilities—again it seems pretty much like what EA is or should have been doing all along, aligning business and technology investments with a focus on reducing gaps, redundancies, and inefficiencies.

I’ve seen other people including some prominent computer and consulting vendors present this topic as well, and aside from pushing there wares, have seen them fall all over themselves tying to define and explain SOA. Honestly, it was pathetic!

Finally, I have seen one impressive implementation at a government agency, and it did actually have savings associated with it, but the application was done a few years back, was relatively small, and there has been little to no movement on further SOA development since (except for the purchase of an enterprise service bus) even though there is a mandate in this agency to implement SOA.

In fact, at a recent meeting with the business side from operations, the presenters said that they were going to spend oodles of money rewriting one (if not the) major operational application for the agency (over 1.2 million lines of code and growing) to make it .NET compliant. I asked the business if they were going to take this opportunity to do this using SOA, and they said no, they just want the same functionality as before!

So in the end, if the business doesn’t want it and the vendors and consultants can’t explain it, the final question with SOA is does the emperor really have clothes?


Share/Save/Bookmark

August 31, 2007

SOA Best Practices

I came across these Service-Oriented Architecture (SOA) best practices and thought they aligned well with User-centric EA and were worth sharing:

(adapted from Naval Post Graduate School, Monterey, CA, Masters Thesis—SOA for Coast Guard Command and Control by Dash and Creigh, March 2007 — approved for public release):

  • Know when to use services – Explicitly define the extent to which we will and will not use services; services are selected with intent and do not randomly spring up.
  • Think big, start small – This allows us to validate the architecture, while giving the organization value, realized as usable services.
  • Build on what you have – Reuse legacy application functionality and data wherever possible.
  • Use SOA to streamline business processes – SOA is an inherently flexible and interoperable model for hosting application functionality; this provides an opportunity to rethink and improve business processes.
  • Incorporate standards – Use industry web service standards for navigation, application logic, integration, data stores, and enterprise infrastructure.
  • Build around a security model – Functional design needs to be built around security, and not vice versa (security cannot be added as an afterthought).
  • Design with quality in mind – Quality must be designed into the product, and not inspected into it.
  • Organize development resources – Group development team around logical business tasks, and not around technologies.
  • Train developers – Ensure designers and developers have the skills to implement SOA properly.

Basic definitions:

SOA is a software design methodology that uses loosely coupled services to perform business functions and processes.

A service is an implementation of a well-defined piece of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.

In general, I think SOA is a great fit with User-centric EA, because the focus is on providing functional business services to the end-user, as opposed to developing monolithic, stove-piped, and redundant applications. The end-user should not have to use countless non-integrated applications systems (or even computers) to get their information, but rather the information should be technically transparent and readily accessible based on their business requirements.


Share/Save/Bookmark

August 3, 2007

Is SOA like Legos?

A “service” is a repeatable business task. In Service Oriented Architecture (SOA), applications are built by assembling shared, reusable, modular services into automated business processes.

In SOA, applications development shifts from technology-driven with a focus on functions and features to business-driven with a focus on business processes and services.

SOA aligns well with user-centric EA where business is the driver for technology, rather than technology for its own sake.

In the Wall Street Journal (July 30, 2007), Meg McCarthy, the CIO of Aetna, compares SOA with Legos: With Legos, we have distinct pieces that can be joined and formed into a functional object and then can be taken apart and put together again in a different way, for another use. Similarly, in SOA, we have loosely coupled services linked for use in discrete tasks, and which can then be linked in alternate ways and reused for other tasks.

In SOA independent, interoperable software can be searched, discovered, and exchanged/shared. Thus, integration is achieved by invoking service calls for necessary information and functionality.

One example where we can benefit from integration and sharing is in government in today’s post 9-11 world, where inter- and intra-agency information sharing is vital for law enforcement and defense readiness.

SOA leverages modularity and component reuse to achieve a more agile IT environment that can more efficiently automate business processes and integrate our silos of people, process, and technology.

Have you seen any examples of SOA in action?


Share/Save/Bookmark