Real World SOA | David Linthicum | May 2007

MORE ENTRIES

May 2007

May 31, 2007 | Comments: (0)

Why SOA Governance Needs to do a Better Job with Data

As I've been looking at SOA governance solutions recently, I've been looking at a huge hole in the approach. While all SOA governance products do indeed consider the control and use of services, most are ignoring the data management issues, and thus are only solving part of the problem.

Services are really transactional behavior that fronts information, at their essence. While there are services that are built as true data services, and services that are more about transactional behavior, they are all services nonetheless and all must deal with, and manage information/data.

Design time and run time SOA governance products, while taking into account the concept of a service, typically skip over the concept of data management, specifically abstraction from the physical database, as well as the management of changes from orchestrations, to composites, to abstractions, and then to the physical data. Right now, most SOA governance systems deal with services first, data second, or not at all.

Considering this, those leveraging some of the SOA governance products out there may find that the coupling of the physical data structure to the services limits the ability for the architecture to provide agility. Moreover, as the data changes, SOA governance needs to account for changes and the impact to the service or services…a design time concept. Moreover, policy management during run time may not extend to the underlying data as well, and could cause issues considering that the services are not managed as a holistic unit.

My advice is to pay more attention to the data when considering SOA governance. The services are important, but they typically deal with information, and it's critical that we pay attention to that as well, else we're only solving part of the problem.

Posted by Dave Linthicum on May 31, 2007 12:54 PM

May 29, 2007 | Comments: (0)

5 Things HP Needs to do to make an Impact in the SOA Market

As we saw last week HP has tossed its hat into the SOA market, and is ready to do battle with the likes of Tibco, IBM, and Oracle.

"HP has decided that the time is right for SOA, so is stepping onto a battlefield currently being dominated by IBM. Unlike Big Blue, however, The Garage will be working with a number of middleware vendors--including Oracle--to deliver its SOA solutions. Its core technology came to HP in last year's $4.5 billion acquisition of Mercury and its Systinet technology in July 2006."

So, they have a SOA governance tool, a SOA testing tool, and a good track record in the system management world. So, what else is missing? How about a TLA (three letter acronym)...BTO.

"HP's Business Technology Optimization (BTO) for SOA is 'an integrated set of software and services designed to help customers address...control over the lifecycle of services creation and reuse, reducing risk, managing services and applications, identifying and resolving SOA-related problems, and utilizing services regardless of the underlying integration platform,' HP said in an official statement related to the announcement."

The issue here is that HP is rather big, and their SOA offering is rather small, with others providing more in their stacks. However, the governance tool that HP now owns is first rate, and that's a good foundation for other synergistic products and an overall strategy. Here are a few things they can do to make a larger impact in a market, now that it's moving faster and faster.

The most important issue is the creation of a very detailed SOA product technology strategy that defines both problem patterns and solutions patterns, using the HP SOA technology. Moreover, be honest about what's missing, and thus has to be augmented either though a partnership with another SOA technology, say development, and what HP plans on buying or building in the future. Some of this is public, some of this is not.
Once the strategy is complete, it's time to define the stack roadmap. Not product roadmaps, but a detailed plan that shows the maturation of the product over time and the interdependencies with other products in the portfolio, hopefully increasing. Moreover, link this back to step 1.
Be unique in the offering, perhaps providing a SOA governance repository with examples of best practices already populated. Thus, SOA practitioners don't have to start from scratch. Or, perhaps a directory of Internet delivered services, thus saving the practitioner for having to find them and enter them.
Provide a good SOA modeling tool. Nobody has one of those yet…I'm still looking.
Become the best at leading thought around SOA. IBM does a good job in providing key information around SOA concepts. However, I'm talking about step-by-step guides, such as "when your domain looks like this, use this approach and technology." Practitioners are starving for guidance out there, vendors who provide it will lead the market eventually.

Posted by Dave Linthicum on May 29, 2007 04:53 AM

May 26, 2007 | Comments: (0)

Holiday Hours

There will be no new Podcast this week due to the holiday. I will have a new Podcast the following week, on June 4^th. Good time to listen to the archived Podcasts as you bake in the Memorial Day sun, or run off that BBQ.

Vendors and PR agencies. Those of you looking to schedule a briefing, next week is fairly clear (Tuesday through Friday), but not after that. So, all those who have been chasing me, now is your chance.

Please:

Be SOA or Web 2.0 related.
Have something new and exciting to report.
Leave the marketing materials out of the pitch (can you say "agility" 100 times).
Provide key information in advance, and contact information for everyone doing the briefing.
Be nice to me.

Keep in mind while I behave, look like, and act like a member of the press I'm really a meat eating SOA practitioner, so treat me accordingly.

You can contact me at david@linthicumgroup.com.

Posted by Dave Linthicum on May 26, 2007 07:35 AM

May 25, 2007 | Comments: (0)

Steps to Help SOA Succeed

Kurt Mackie, at ADTMag.com, was evidentially sitting in the audience during my talk at the Enterprise Architecture Summit held earlier this week in Palm Springs CA. He did a better job in summarizing my presentation than I could.

"Service-oriented architecture (SOA) is an approach that has garnered lots of big ideas, plus there's technology complexity to boot. However, a best-practices talk by David Linthicum, a consultant with Linthicum Group, provided an outline for understanding SOA in a world where 'the hype is huge.' Linthicum recently spoke on the topic of 'Steps to Make Your SOA a Guaranteed Success' at Enterprise Architect Summit 2007."

"Linthicum said that the basic idea for SOA has been defined and now it's a matter of getting it to work. The buzzwords are new, but the issues are old. Namely, SOA is about people. In contrast, the technology issues are simple, he said."

And Kurt summarizes as my summary of "Good and Bad Practices."

"SOA is needed to improve an organization's adaptability and agility. Its benefits include functional reusability and supporting change management. It also affords interoperability instead of point-to-point integration, as well as overall orchestration, Linthicum said.

Bad SOA practices include selecting a technology before understanding an organization's requirements and needs. Another fault is not linking back to accepted enterprise architect best practices. Other SOA mistakes include not creating a business case, using the wrong people and a general lack of funding and empowerment.

So what are the best practices in implementing SOA? Linthicum listed a few:
Make sure you do SOA right the first time.
Don't be afraid to experiment. When a mistake happens, admit you're wrong and try again.
Keep vendors working with you and empower those working for you.
Learn all you can, but don't get caught up in the hype.
Don't wait for standards to emerge. Standards have become marketing tools for some companies.
Small battles win the war.
Give yourself plenty of time -- never skimp on any of the steps. "

Have a great 3-day weekend.

Posted by Dave Linthicum on May 25, 2007 03:50 AM

May 24, 2007 | Comments: (0)

So, How Do You Test an SOA?

So, does testing change with SOA? You bet it does. Unless you're willing to act now, you may find yourself behind the curve as SOA becomes systemic to all that is enterprise architecture, and we add more complexity to get to an agile and reusable state. If you're willing to take the risk, the return on your SOA investment will come back three fold…that is, if it is a well-tested SOA. Untested SOA could cost you millions.

Truth-be-told, testing SOAs is a complex, disturbed computing problem. You need to learn how to isolate, check, and integrate, assuring that things work at the service, persistence, and process layers. The foundation to SOA testing is to select the right tool for the job, having a well thought out plan, and spare no expense in testing cycles else risk that your SOA will lay an egg, and thus have no creditability.

Organizations are beginning to roll out their first instances of SOA, typically as smaller projects. While many are working fine, some are not living up to expectations due to quality issues that could have been prevented with adequate testing. You need to take these lessons, hard learned by others, and make sure that testing is on your priority list if you're diving into SOA.

So, how do you Test Architecture? The answer is, you don't. Instead you learn how to break the architecture down to its component parts, working from the most primitive to the most sophisticated, testing each component, then the integration of the holistic architecture. In other words, you have to divide the architecture up into domains, such as services, security, governance, etc., and test each domain using whatever approach and tools that are indicated. If this sounds complex, it is. Indeed, the notion of SOA is loosely coupled complex interdependence, and thus the approach for testing must follow the same patterns.

What is unique about a SOA is that it's as much a strategy as a set of technologies, and it's really more of a journey than a destination. Moreover, it's a notion that is dependent upon specific technologies or standards, such as Web services, but really requires many different types of technologies and standards for a complete SOA. All of these must be tested.

You can group the testing domains for SOA into these major categories:

Service Level Testing
Security Level Testing
Orchestration Level Testing
Governance Level Testing
Integration Level Testing

The categories or domains that you choose to test within your architecture may differ due to the specific requirements for your project. Moreover, there are other areas that need attention as well, including quality assurance for the code, performance testing, and auditing.

At the end of the day you'll find that SOA testing incorporates all of the testing technology and approaches we've developed over the years for other distributed systems, and adds some new dimensions such as services, orchestration, and governance testing. Those who understand testing will have to expand their skills and understanding to include those new dimensions. Many failed SOA projects are directly attributable to lack of testing…many assuming that the new technology would work flawlessly. Unfortunately, that's just not the real world yet.

Posted by Dave Linthicum on May 24, 2007 05:35 AM

May 23, 2007 | Comments: (0)

Audio and Presentation from the “Full Contact SOA” Keynote

Download file

Posted by Dave Linthicum on May 23, 2007 06:01 AM

May 23, 2007 | Comments: (0)

Feedback on the Keynote Podcast

Came across Loraine Lawson's post pertaining to my last podcast of my keynote presentation at InfoWorld's SOA Executive Forum.

"Dave Linthicum is one of the best consultants to read when it comes to SOA. He spends a lot of time speaking on the conference circuit; his blog posts on InfoWorld always seem to be published while he's traveling to or from some city."

Too much time if you ask me. Now that I'm a "hired gun" you have to balance the speaking opportunities with the working opportunities. I teach more when speaking, but learn more when doing. The trick is finding a balance.

"He also spends a good chunk of time talking about the Bad Practices in SOA implementations. He identifies these as:
Selecting SOA without understanding the business requirements or needs. As a consultant, the first thing he does when he works with a business is to rip things out of his stack that customers don't need. Beware of vendors selling you more than you can use.
Not linking back to accepted EA standards and best practices.
Not creating a business case. You must understand the business impact and benefits or, he suggests, you shouldn't try it.
Using the wrong people, who lack funding and empowerment."

A lot of the meat came towards the end of the presentation, unfortunately. I may upload entire audio to this blog, still need to put up the presentation up there as well.

Posted by Dave Linthicum on May 23, 2007 05:49 AM

May 22, 2007 | Comments: (0)

Keynote Presentation at the SOA Exec Forum...Full Contact SOA

Download file

Posted by Dave Linthicum on May 22, 2007 04:57 AM

May 21, 2007 | Comments: (0)

The Open Group's Allen Brown and the Changing Nature of Enterprise Architecture

I had a chance to meet Allen Brown, CEO of the Open Group, over the weekend, specifically on the golf course Sunday morning in a golf event sponsored by the Enterprise Architecture Summit held this week Palm Springs California. Allen and I managed not to embarrass ourselves on the links, indeed I was pleased with my game. I don't remember what we shot, but clearly Tiger Woods' job is safe. I have not played 18 holes of golf in a year, too many other priorities, such as this blog.

This morning Allen did a talk on the changing nature of enterprise architecture, here are some of the highlights from his talk:

Allen questioned the role of technology, and talked about how the I in IT, or information would be the focus going forward.
This leads to the "5^th Information Revolution" as defined by Drucker.
History is repeating itself, "software development with its focus on technology, is being off-shored and outsourced."
Their place is being taken by architects, focusing no longer on technology, but information.
Need to go outside of the enterprise for information. That information we used for making business decisions.
The problem is that we've been set up within silos, and we've been working get create cross functional teams that span the silos. While there is some success, typically this is very hard.
Thus, there are multiple systems, conceived and developed individually, compounded by the problem of cross-functional teams.
Need to raise the level of professionalism around enterprise architecture.
- Should be professionals such as accountants, lawyers, doctors, etc.
- Provide a way that employers can look at people, and understand that they are indeed enterprise architects.
- Need the right qualifications to drive enterprise architecture.
The Open Group provides the Association of Open Group Enterprise Architects (AOGEA). This is for individuals, raising the level of professionalism.
The Open Group uses TOGAF Architecture Development Methods which provides the toolset. They are now on TOGAF 8. "Standards for doing architecture."
TOGAF is compatible with other major EA frameworks, such as the Zachman Framework, and the Federal Enterprise Architecture Framework.
Then Allen went into the qualifications for their ITAC Program (Industry IT Architect Certification).
The Open Group has a SOA workgroup defining what they meant by SOA, and the mission of the workgroup, and what are the things they are going to work on. SOA is a style of architecture, according to the workgroup, and is able to coexist with existing enterprise architecture approaches such as TOGAF.

I like discipline around enterprise architecture and SOA, so what the Open Group is proposal is a good thing. The issues are around the number of competing ideas and concepts out there now, both within industry organizations, such as Open Group, and even vendors organizations, such as Microsoft, IBM, and Oracle. Around SOA this is very hype-driven, and confusing.

The core issue here is driving this into the industry so that people think about it as a true professional organization. This is really good for SOA as well, considering that there will be a common architecture framework around SOA, and standard frameworks and approaches.

Posted by Dave Linthicum on May 21, 2007 09:59 AM

May 21, 2007 | Comments: (0)

Salesforce.com Announces Salesforce SOA

With many things leading up to this, today Salesforce.com announced that they are indeed now an on-demand SOA solution, considering the capabilities of their Apex platform, new and existing. This includes adding new capabilities such as an add-on to its Apex development environment that allows users to access external web services.

Their on-demand platform has been evolving for some time now, and now they are moving into the SOA space with an offering that's both disruptive and innovative. I'm not sure too many out there saw "SOA on-demand" coming, but if anybody can pull it off Salesforce.com can.

"Santa Clara, Calif. – Salesforce Developer Conference -- May 21, 2007 – Salesforce.com (NYSE: CRM), the market and technology leader in on-demand business services, today announced Salesforce SOA, taking service oriented architectures on demand for the first time. Salesforce SOA will deliver SOA as a service, heralding the end of complex and expensive software-based SOA solutions for intelligent Web services integration. Salesforce SOA is a powerful new capability of the Apex programming language that will allow developers to focus on innovation, not infrastructure, while building a new class of on-demand applications. Salesforce SOA was unveiled and demonstrated today at the Salesforce Developer Conference."

"Salesforce SOA will provide the ability to mashup salesforce.com's multi-tenant on-demand service with enterprise workflow and business processes to enable new kinds of enterprise applications on demand. As a new capability of the Apex programming language, Salesforce SOA will enable SOA-based business processes, such as enterprise applications, to be created, maintained and leveraged on demand. SOA business processes will become virtual and sharable, and benefit from the scalability and agility of the on-demand model. With Salesforce SOA, developers will be able to:
Use Apex to build SOA applications that integrate to Web services from billing, inventory or order entry systems.
Call out to internal Web services such as Oracle Financials and SAP Order Management, and external Web services such as FedEx, Hoovers and Yahoo!.
Build rich applications on-demand for any business process"

The multi-tenant Salesforce Platform provides a feature set for building business applications such as models and objects to manage data, a workflow engine for managing collaboration between users, a user interface model to handle forms and other interactions, the Salesforce API for programmatic access, mash-ups, and integration with other applications and data, and the Apex programming language.

This is the first step of many that Salesforce.com will take to drive their on-demand platform further into the market. It just makes logical sense when you consider that they are a huge service provider, and the masses are leveraging salesforce.com for their business processes delivered through a subscription-based service. Now, you can take those processes and services and bind them to process and services inside your enterprise, between your customers and partners, and do so using an SOA infrastructure that you also leverage using a subscription service. It's also an application development platform, allowing you to create and integrate your own on-demand business applications.

Those that will leverage "Salesforce SOA" now will include current Salesforce.com subscribers that need to integrate their internal processes and services with Salesforce.com, and build new businesses processes and new application functionality as well. They will find this approach more cost effective.

As the Salesforce.com SOA stacks gets more mature and better known Salesforce.com may find that "Salesforce SOA" users, many who are not current Salesfroce.com subscribers, will be leveraging "Salesforce SOA" as an inexpensive way to get into the world of SOA, and I think that if they are successful using the SOA platform, most will stay.

Finally, larger organization may found that "Salesforce SOA" is mother of all SOAs when it comes to binding enterprises together to form value chains, or even integrating distributed companies into a single collection of services, using "Salesforce SOA" as a mechanism for central interoperability, as well as service and process exchange. Moreover, the world of mashups is exploding and this platform is perfect for supporting a mashup creation platform on-demand.

It will be interesting to see how the larger SOA stack players react to this announcement. Now, SOA architects, developers, process designers have a less expensive way to build, deploy, orchestrate, and manage services using a holistic, single source stack. The best-of-breed players will actually benefit from this technology. You still need bit players to bring it into the enterprise, abstracting and managing data movement, interfacing with core systems, and even building SOAs that interact with an on-demand SOA such as this.

Clearly, market changing technology.

Posted by Dave Linthicum on May 21, 2007 06:44 AM

May 18, 2007 | Comments: (0)

Rank Your SOA Vendor

I happed to catch this post by Mark Fralick, Technology Editor, Supply Chain Digest who has a rather cool way of ranking SOA vendors. Mark talks about the hype, and how to see the core value of SOA beyond the hype.

"Here's my suggestion – fill out the following SOA scorecard for each vendor:
If they talk about the technology of SOA (their implementation of it) – give them 1 point.
If they misspell SOA on any slide. Take away 1 point.
If they do not know each word making up the acronym SOA, take way 1 point for each of these words.
If they pronounce S.O.A as "So-A", take away 1 point.
Add 5 points if they can use Web-Services based Integration. A Web Service is an implementation standard for SOA. Take away 10 points if they did not know this.
Add 20 points if they talk about it in terms of functionality and not so much in terms of technology – and can show how to shift the functionality around or move it outside the application."

Mark goes on to say:

"If they score between 5 and 10 they probably have some SOA capability. If they score over 20, they are probably pretty far along the spectrum. But, my tongue in cheek scorecard highlights the most important thing about SOA. While SOA is enabled by technology and architectural approach, its real value is to the operation and the enterprise's business processes."

Here's my SOA scorecard:

If they say "agility" and/or "reuse" more than 100 times in the first 10 minutes take away 10 points for being too "hype-y."
If they can't tell you how their product works and plays with other products, that's a 10 point deduction as well.
If they promote a standard that's only in draft, that they wrote, as the savior of SOA, that's a 20 point deduction for being naive.
If they give you a mug, add 5 points.
If they can tell you in detail how to leverage their product, including a step by step guide to implementation, add 50 points.
If they admit limitations to their product up front, so you don't have to guess, give them 30 points for honesty.

Posted by Dave Linthicum on May 18, 2007 07:07 AM

May 17, 2007 | Comments: (0)

Linking Processes to Services = SOA

Yesterday at the SOA Executive Forum I moderated the "Bridging the Gap between Process and Services" panel. Basically the idea was that:

"SOA is a conversation between IT and business. Mapping out business processes is an essential first step, but converting that map into an array of services is tricky business."

The other panelists were:

Mighael Botha, Technology Evangelist, Software AG

Marvin Richardson, Managing Director & Co-Founder, Trexin Group, LLC

Derek Sampson, Sr. Director, Back Office Architecture, Comcast

Sumitro Sarkar, VP, Technology Strategy, Thomson Financial

Elizabeth Book already beat me to the blog punch on this, but I wanted to add my perspective, and summarize the comments from the panel.

SOA has always included business processes, so this is not a new concept. However, many people think it's new.
Processes are able to abstract distributed services turning them into solutions within a SOA.
Volatility should exist at the process layer, according to me, however Marvin also thought that in some cases volatility can exist at the services layer as well.
Performance a testing should be considered always, not matter how you implement your processes.
Standards are helpful, but should not control your processes layer completely.
Planning and good architecture lead the day.

Good set of brains on the panel, I thought it was very interesting.

Posted by Dave Linthicum on May 17, 2007 05:22 AM

May 16, 2007 | Comments: (0)

Who's Blocking SOA?

There has been a lot of blogging going on around the notion of SOA adoption. Specifically, ZapThink's Ron Schmelzer post, and Joe McKendrick response around Ron's assertion that SOA is making more sense to business than IT. Indeed, that in many instances, IT is blocking the adoption of SOA.

While I can see Ron's point, it's been my experience that SOA adoption seems to come from two directions, considering my practice. First, more innovative IT organizations, those who want to begin to experiment with the notion of SOA, and typically do so outside of the control of the business. We can call this the technology sell. Second, interest in SOA is driven from the business guys, typically CIOs and CEOs that are responding to their understanding of the value of SOA, and are pushing their IT organizations to examine its potential value. We can call this the business sell.

To Ron's point, within that second scenario there is indeed resistance from IT. Not complete and utter pushback, just cautious around the issues with the adoption of any new technology and approaches. In these situations I spend more time going after hearts and minds than pushing the technology and approach…the technology is easy, hearts and minds are not.

So, what does one do?

Understand that you need to approach all enterprises and problem domains differently. While many IT organization are ripe and ready for SOA, and need little selling just coaching, other's find the notion a bit threatening, something you address with education not force.
Sell the value not the technology. The technology will work. Getting people to understand the value is something is a bit more difficult.
Keep in mind that some organizations are going to adopt SOA slower, or faster, than other organizations. Thus, you need to consider the "ability to adopt" as a key variable when working with enterprises on SOA.

Posted by Dave Linthicum on May 16, 2007 06:52 AM

May 16, 2007 | Comments: (0)

Building an SOA that Scales

Tried to post yesterday, but Word locked up when I attempted to transmit to the blog site. Word 97, the jury is still out for me. Anyway, I did moderate the panel: Building an SOA that Scales.

Here is the description:

"The great thing about SOA is that you can start small. But how can you build to one set of requirements while keeping long-term SOA goals in mind? Here are the technology and governance issues to consider."

The panelist where:

David Chappell, VP & Chief Technologist, SOA, Oracle

John Daly, VP & GM, Global Architecture Services, Keane, Inc.

Daniel M. Foody, VP of Actional Products, Progress Software

W. George Glass, Chief Architect & Director, Platform Design & Build, BT Exact

Eric Newcomer, CTO, IONA Technologies

The takeaways from the panel where:

Focus on the architecture as a holistic unit; make sure to consider all components. Keep in mind that your ability to scale is limited by your slowest component.
Consider standards, but don't let them lead you. Make sure you focus on what you need, and your requirements now, and into the future.
Metadata and schemas need to be considered along with scalability, and abstraction layers provide additional agility.

Here goes, I'm pressing the button.

Posted by Dave Linthicum on May 16, 2007 05:33 AM

May 15, 2007 | Comments: (0)

SOA Exec Forum Podcast

Download file

Posted by Dave Linthicum on May 15, 2007 07:34 AM

May 12, 2007 | Comments: (0)

SOA Exec Forum Next Week

I'm on a train on Monday heading up to NYC for the InfoWorld SOA Executive Forum, taking place on Tuesday and Wednesday. I'll make sure to blog from the event as much as I can, for those of you who can't make it.

On Tuesday I'm doing a keynote talk on "Full Contact SOA." As the name implies, it's really about diving in and making SOA work at the project, not theory level, something I've been doing a lot of lately.

So, what's the 411 on Full Contact SOA? Here are a few highlights:

The technology is easy, the people are hard. You need to figure out both the culture and the people in order to make SOA a success. I've never meet a problem I could not solve with technology, but the hearts and minds are another level of play.
Focus on using the best technology, not the technology that's easiest to use. Many out there are playing the "mega stack" game, buying all of their SOA technology from a single source. You may get some of that right, but never all of it. Keep that in mind. Always follow your requirements, never follow the technology hype.
Work a holistic strategy around many projects, not a single huge SOA project. Small wins add up to larger strategic gain for your business.

See you next week. If you would like to meet at the conference, drop me a line.

Posted by Dave Linthicum on May 12, 2007 04:47 AM

May 09, 2007 | Comments: (0)

Web Services and Federated Identity

Sorry for the late blogging, I've been at the 2007 Web Services Security Conference and Exposition held near Baltimore MD. I did the keynote presentation at 9:00 AM on identity management strategy. Also, the panel at 1:00 PM also on identity management. No WiFi there…there should be a law. :-)

Since the advent of Web services, and other distributed computing standards for that matter, we've been wrestling with the notion of identity and how to manage it. Truth-be-told identity management has been put on the back burning are organization attempt to get their first Web services projects up-and-running. However, as Web services become more pervasive, this is an issue that is getting more attention.

With the increasing interest in identity management so has risen the need for standards to better define this space. These standards are all aiming at binding together identity management systems within all organization into a unified whole, allowing for everyone to be know to everyone else, securely.

So, why do we need identity management? It's the fact that Web services are not for internal use anymore, and those who leverage Web services (consumers), or produce Web services (provider), need to know known to each, else we risk invoking malicious or incorrect behavior, which could cost us dearly. This is clearly the case within trading communities that leverage Web services. Many outside organizations are binding to your services and you to theirs, and the potential for disaster increases, unless you know just who you're dealing with.

Identity is important in the growth of sensitive data and confidential relationships online. Lacking identities there is no way to provide certain users with access to certain resources.

Today, we use managed identities, including different user names, passwords, and other identifying attributes. The same person may have links to many organizations, including frequent flyer sites, banking sites, employee benefit sites, etc.. Perhaps you have a list of user names and passwords in your drawer today.

The number of identities that we have creates a challenge. We've all written down user IDs and passwords on sticky notes just to remember them. Moreover, IT organizations find it increasingly difficult to manage the profusion of identity databases, even within their own organization. The problem becomes more of an issue as we extend our reach outside of the firewall, inter-organization. Enter federated identity and potential solution to this problem.

Federated identity, including supporting standards, such as those from OASIS and the Liberty Alliance project are defining mechanisms that organizations may employ to share identity information between domains. While most understand the value of an identity management systems internal to an enterprise, federated identity presents a new set of problems, and an opportunity for solutions.

There are many benefits to employing federated identity solutions including the ability to perform logging and audit functions centrally, reducing costs associated with password reset, and access to many existing heterogeneous application securely.

Posted by Dave Linthicum on May 9, 2007 03:12 PM

May 07, 2007 | Comments: (0)

SOA, the Good and the Bad

Download file

Posted by Dave Linthicum on May 7, 2007 08:50 PM

May 07, 2007 | Comments: (0)

Canadians Falling Behind in SOA Adoption

According to this article in IT Business, a Canadian IT magazine, while Canada leads in many areas, SOA is not one of them.

"The concept may be hot, but the adoption rate is not, according to a Canadian IDC analyst."

While SOA moving steadily in the US and Europe, the mostly mid-market Canadian businesses don't feel the need, or perhaps can't afford to move into SOA just yet, according to the article.

"The lag is evident when Canadian companies are compared to their U.S. counterparts, who currently hold a strong lead in SOA adoption, said Senf. This is because Canada is primarily a mid-market country, with a manufacturing-heavy industry that tends not to be early adopters of this type of technology, he added."

"He said organizations passive to SOA view the architecture as 'just another tool in a toolbox to get something done,' rather than using it to transform the business."

"But therein lays the issue behind SOA adoption, because most companies don't see its business value, nor do they feel they can afford it, or have the SOA skill set among their IT functions to deploy and maintain it, he said."

The issues are real. If you're a small or midsize company you will find it's hard to afford new laptops for your sales people, not to mention a systemic change in the way you do IT. Thus, many in Canada are sitting out the first waves of SOA. I actually can understand that, and don't really think it's a bad thing. Indeed, I run into companies all of the time that don't have the resources to really take advantage of SOA, at least for now. Actually, I would rather have them wait and succeed later, versus attempting to do something now, with too little, and fail. The buy in for SOA is pretty high, as I've been saying.

I suspect the Canadians will come around to SOA in their own time, and on their own terms. However, I do think some of those companies need to set up their strategy now, and do the work later. Many are doing nothing at all, and it will be tough to go through the learning curve later...believe me.

Posted by Dave Linthicum on May 7, 2007 05:25 AM

May 03, 2007 | Comments: (0)

SOA, on Demand?

If you've been monitoring my career, as well as my postings, you already know that I'm bullish on SaaS, and SOA, and I see the two merging as complementary concepts. Indeed, we're now seeing SaaS companies move into the platform space, selling beyond enterprise applications into databases, application development, integration, and even operating systems, all on demand. Case in point is this release by Salesforce.com, outlining their new on demand platform that provides many core app dev and SOA tools, and does so on demand.

"'Salesforce Platform Edition heralds the arrival of salesforce.com as a platform company as well as an applications company,' said Marc Benioff, salesforce.com chairman and CEO. 'With Salesforce Platform Edition, customers can now easily extend the power, usability and success of on demand to every part of their enterprise. ISVs can deliver their applications to run directly on the Salesforce Platform Edition---allowing our customers to manage and share all of their information on demand.'"

You should check out their white paper, which can be found here.

An on demand platform supports multi-tenancy. In contrast to single-tenant counterparts, multi-tenant platforms share a single, common infrastructure and code base that is centrally maintained. Individual customer deployments are unique, separate, and secure within this shared multi-tenant platform, and run a single code base that is shared by all users and upgraded simultaneously.

So, why should you care? Well, this does indeed change the games of both enterprise architecture and SOA. It does not change the core concepts, but the fact that as an option, you can obtain the use of the key technology on demand, through a subscription, and thus at a fraction of the buy-in price we're paying now for software and hardware we host on our own. This means that SMBs can be on an equal playing field in the world of SOA, as compared to the Global 2000 who can spend the big bucks on the big SOA vendors. Moreover, an on demand platform also provides a single location for sharing services and tools, single global repository and directory, and the ability to get out of the constant struggle and expense of keeping your software and hardware stack current.

Again, this does not change the core notion of SOA, only the ways to deploy it. This could make SOA much more affordable and easier to implement, also allow resources to be shared on demand. Those are good things.

Posted by Dave Linthicum on May 3, 2007 06:53 PM

May 02, 2007 | Comments: (0)

ROI, ROI, ROI,...and SOA

I was at Booz Allen yesterday in Tyson's Corner Virginia to do a ROI and SOA presentation for their consultants, there in person and on closed circuit video. Good group of people, and they are now serving the government's SOA needs, perhaps leading the way in some respects.

The ROI issues are taking center stage these days now that SOA projects are starting all over the world and the execs at these organizations, both government and commercial, are asking: "How much money will this save us?"

The notion of ROI and IT has always been a tricky issue. While there are common metrics that one can put forth around the value proposition of IT in general, or a specific approach such as SOA, the fact is that you need to look closely at the particular problem domain to come up with approaches to ROI that are useful. There are two major dimensions here, first the influence of the business, and the realities of the technology.

The business is the single most critical dimension when you consider the ROI of SOA, which is surprising to most that are promoting this technology. Truth-be-told the business needs to value certain things in order for SOA to be valuable, namely an agile architecture that is able to quickly align with the business. Old news in the world of SOA, but the value of SOA really relates to the business' ability to change, and support a culture of change. You can have the greatest, most agile, SOA in the world, but if you're not able to change the business, perhaps the culture does not support it, than the SOA will have little value. If you value change, and can change, then SOA has a huge value.

The technology is easy, when you compare it against the difficulties with changing business and culture. The ROI of the technology is directly related to the cost of the technology as compared to its value. I've not run into any problem I could not solve using technology. However, the real trick is leveraging the right technology that meets the requirements, thus minimizing costs, and maximizing impact. By doing that you're maximizing ROI.

My ROI work is heating up, glad the interest is there. I think it's healthy.

Posted by Dave Linthicum on May 2, 2007 07:26 AM

May 01, 2007 | Comments: (0)

Interview with F5's Lori MacVittie Talking about SOA Security

Download file

Posted by Dave Linthicum on May 1, 2007 04:22 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •