Real World SOA | David Linthicum | November 2006

MORE ENTRIES

November 2006

November 29, 2006 | Comments: (0)

Hey, I woke up this morning and created a buzzword...blurring.

"Blurring" is the notion of blurring the line between your enterprise applications, and services and information found on the Internet. Or, blurring the lines between your SOA and the emerging Web 2.0.

As more enterprise applications become "service enabled" these applications and service oriented architectures (SOAs) can now easily leverage Web services that are Internet hosted. These services include:

- Search engine APIs/services, from providers such as Google and Yahoo.
- Services that are a part of SaaS providers, such as Salesforce.com.
- Services that are part of vertical market exchanges.
- Services that exist within trading partners.

The advantage of blurring is that those tasked with building enterprise applications can now leverage Web-based services that they did not have to create themselves. Allowing developers to mashup those services with existing enterprise systems, know as enterprise mashups. Typically this is done within the context of a SOA.

The notion of blurring will only continue as the number of Web-based services become more pervasive and feature rich. Indeed, blurring could change the way we build and deploy applications going forward, and builds on the notion of SOA.

Please using the term blurring as often as you can. Remember where you heard it first.

Posted by Dave Linthicum on November 29, 2006 07:34 AM

November 27, 2006 | Comments: (0)

Report from the SOA Kongress and BEA’s SOA Survey

Report from the SOA Kongress and BEA's SOA Survey
Download file

Posted by Dave Linthicum on November 27, 2006 09:23 PM

November 26, 2006 | Comments: (0)

Beware of SOA Vendors Wearing SOA Methodologist Clothing

These days SOA methodologies; meaning approaches, game plans, check lists, whatever...are everywhere. Indeed, there are many out there who would like to tell you how to go about building your SOA. I guess that would include me if we're being honest.

It's tempting. I mean this stuff is relatively new, and many organizations are seeking guidance...where to start...what to do...and how to do it. However, some of the vendor delivered methods I'm seeing out there could do you much more harm than good.

First of all, don't get me wrong, methodologies are good. It's helpful to have a set of procedures, instruction, or other guidance when you're looking to build something as complex as a SOA. Indeed, we've been using methods for years, including methodologies for structured analysis and design, object-oriented analysis and design, "traditional enterprise architecture," and now SOA. But, while using "a SOA methodology" is typically good, using a bad SOA methodology will kill you. That's the issue here.

Many SOA vendors are selling services now, along with guidance pertaining to the implementation of SOAs, including requirements, technology selection, and more technology selection, typically without useful steps such as understanding your own domain properly and selecting best-of-breed technology. For instance:

1. Understand how You can Use Our Technology
2. Select Our Technology
3. Define the Value of Our Technology
4. Reselect Our Technology
5. Go to Steps 2 or 4
6. Pay Your Bill Promptly

While I am being a bit flip here, this is not far off what I'm seeing out there. Moreover, I think many organizations are not spending the time they need to understand their own issues, and typically selecting the wrong technology for their requirements based on vendor advice. The result is a SOA that is not at all aligned with their business requirements, and an IT architecture failure that will drive the organization back to the drawing board. This not only wastes the dollars spent on the consulting and technology, but loosing the strategic advantage of having an agile architecture up-and-running sooner.

So, how do you know you're using a good methodology?

First of all, I would avoid using a SOA methodology from a SOA product vendor. Not that the vendor may have nothing but the best intensions, but they typically have a conflict of interest. They are interested in selling technology, not driving you to look at the technology you may need. You can use their services in the POC phases, and if you select their technology in implementation.

Second, make sure the methodology has at the very least the following activities:

1. Define the ROI and align with business
2. Select a domain
3. Semantic-level understanding of the domain
4. Service-level understanding of the domain
5. Process-level understanding of the domain
6. Data abstraction
7. Service design
8. Process design
9. Technology requirements and selection
10. Implementation and testing

Finally, make sure to educate the people in your organization responsible for implementing your SOA, and get the help you need. This is not just changing an application, it's a systemic change in how you do IT going forward, and you need to get it right the first time.

Posted by Dave Linthicum on November 26, 2006 06:24 PM

November 22, 2006 | Comments: (0)

Google is Clearly a SOA Services Company

I'm at the SOA Kongress this week in Mainz Germany, doing my keynote talk this afternoon on the Web 2.0 and SOA. I had the pleasure of hearing Patrick Chanezon, API Evangelist with Google. Great update on what those guys are up to, and clearly they are moving from an information company to a services company, if they have not done so already.

Patrick went over the API strategy at Google, including APIs in the areas of Search, Advertising and Commerce, exposing them using various technologies: SOAP, REST and Ajax. Thus, the extension and sophistication of the already overused mashup concept, with APIs that talk to most core Google engines.

For instance:

The Google AJAX Search API lets you integrate a dynamic Google search module into your web pages so your users can mash up Google search results with other content on your site or add search results clippings to their own content.

The Google Maps API has been around for a year and defined how services could be exposed as javascript components for Mashup type Ajax applications.

The Google Data Calendar API is the first of the new REST Google Data API that lets you search and manipulate Time based information.

The Google AdWords API allows you to automate ads creation and management on Google AdWords.

The Google Checkout API helps you integrate Google Checkout in you ecommerce infrastructure.

And I'm sure they will add more shortly.

What this proves is that the "outside-in services" notion that I keep hitting on is coming true. It's just a matter of time before major enterprise class services come out of the Web as well, not to mention semantic management, governance, security, and all of the on-demand management that's needed with those services. We are already seeing early enterprise-ready services from SaaS players such as Salesforce.com.

Best talk I heard today, and the only one in English as happenstance. By the way, SOA sounds so much more confusing in German.

Heading back tomorrow, yes on Thanksgiving. Don't ask me how that happened.

Posted by Dave Linthicum on November 22, 2006 08:37 AM

November 21, 2006 | Comments: (0)

What SOA Costs and Can your Enterprise See the Emerging Web?

Download file

Posted by Dave Linthicum on November 21, 2006 07:23 AM

November 19, 2006 | Comments: (0)

How Much Will Your SOA Cost? Here Are Some Guidelines.

I'm consulting now...at the project and strategy levels...and thus finding that a lot of real work needs to get done to get SOAs up-and-running. With most organizations at the initial stages of their SOA project, the first step seems to be is to figure out how much this SOA will cost. Thus, you can budget appropriately, and obtain the funding.

First thing, most organizations building a SOA don't have a clue how to approach this, and in many cases grossly underestimate the cost of their SOA hoping that their bosses and accountants won't notice later. In other words, go in low to get the approval, and reveal the higher costs later after it's too late...the investment has been made. Not a good management practice, if you ask me, but a pretty common.

So, how do you calculate the cost of a SOA? While you can't cost out a SOA like a construction project, many of the same notions apply, including: Understand the domain, understand how much resources cost, and understand how the work will get done. Moreover, understand what can go wrong and account for it.

Here's some "very general" guidelines:

Budget to budget. The problem that I'm seeing over and over again is that cost estimates are provided without a clear understanding of the work needed to get done. Indeed, you need to budget some time to create the budget. This means understanding the domain in detail, including:

Number of data elements
Complexity of data storage technology
System complexity
Service complexity
Process complexity
New services needed.
Enabling technology
Applicable standards
Potential risks

Typically it's expressed as:

Cost of SOA = (Cost of Data Complexity + Cost of Service Complexity + Cost of Process Complexity + Enabling Technology Solution)

For instance:

Cost of Data Complexity = (((Number of Data Elements) * Complexity of the Data Storage Technology) * Labor Units))

Number of Data Elements being the number of semantics you're tracking in your domain, new or derived.
Complexity of the Data Storage Technology, expressed as a percentage between 0 and 1 (0% to 100%). For instance, Relational is a .3, Object-Oriented is a .6, and ISAM is a .8.

So, at $100 a labor unit, or the amount of money it takes to understand and refine one data element, we could have:

Cost of Data Complexity = (((3,000) * .5) * $100)

Or, Cost of Data Complexity = $150,000 USD Or, the amount of money needed to both understand and refine the data so it fits into your SOA, which is a small part of the overall project by the way.

If you get this, you can get the rest of the cost analysis procedure; just reapply the same notions to:

Cost of Service Complexity
Cost of Process Complexity
Enabling Technology Solution

Some things to remember:

1. This is not really metrics (e.g., function points), because we really don't have historical data to abstract here. In essence you need to use your own project management and project costing methods, just apply them to this new approach, using the formulas I'm suggesting above.

2. Count on 10 to 20 percent variations in cost for the simple reason that we've not walked down this road before. As we move from project to project, we'll get better at costing out SOA.

3. Make sure you dial in at least 2 major mistakes, meaning selecting the wrong vendor, or hiring the wrong architect.

4. Make sure to change cost estimates as scope creep occurs, and it always does.

Posted by Dave Linthicum on November 19, 2006 05:57 PM

November 16, 2006 | Comments: (0)

Managing SOA Semantics Using Ontologies and Supporting W3C Standards...Part II

Now, let’s finish up with RDF and OWL...my take.

Resource Description Framework (RDF), a part of the XML story, provides interoperability between applications that exchange information. RDF is another Web standard that's finding use everywhere, including SOA. RDF was developed by the W3C to provide a foundation of metadata interoperability across different resource description communities and is the basis for the W3C movement to ontologies such as the use of Web Ontology Language (OWL).

RDF uses XML to define a foundation for processing metadata and to provide a standard metadata infrastructure for both the Web and the enterprise. The difference between the two is that XML is used to transport data using a common format, while RDF is layered on top of XML defining a broad category of data. When the XML data is declared to be of the RDF format, applications are then able to understand the data without understanding who sent it.

RDF extends the XML model and syntax to be specified for describing either resources or a collection of information. (XML points to a resource in order to scope and uniquely identify a set of properties known as the schema.)

RDF metadata can be applied to many areas, including SOA. One example would be searching for data, and cataloging data and relationships. RDF is also able to support new technology (such as intelligent software agents and exchange of content rating).

RDF itself does not offer predefined vocabularies for authoring metadata. However, the W3C does expect standard vocabularies to emerge once the infrastructure for metadata interoperability is in place. Anyone, or any industry, can design and implement a new vocabulary. The only requirement is that all resources be included in the metadata instances using the new vocabulary.

RDF benefits SOA in that it supports the concept of a common metadata layer that is sharable throughout an enterprise or between enterprises. Thus, RDF can be used as a common mechanism for describing data within the SOA problem domain.

The Semantic Web is the abstract representation of data on the World Wide Web, based on the Resource Description Framework standards and other standards still to be defined. It is being developed by the W3C, in collaboration with a large number of researchers and industrial partners, lead by Tim Berners-Lee.

In order for the Semantic Web to function, computers must have access to structured collections of information and sets of inference rules that they can use to conduct automated reasoning. This notion is known as knowledge representation.

To this end, and in the domain of the World Wide Web, computers will find the meaning of semantic data by following hyperlinks to definitions of key terms and rules for logically reasoning about data. The resulting infrastructure will spur the development of automated Web services such as highly functional agents. What's important here is that the work now being driven by the W3C as a way to manage semantics on the Web is applicable, at least at the component level, to the world of SOA, much like XML and Web services.

An example of the W3C contribution to the use of ontologies is the Web Ontology Language. OWL is a semantic markup language for publishing and sharing ontologies on the World Wide Web. OWL is derived from the DAML+OIL Web Ontology Language and builds upon the RDF. OWL assigns a specific meaning to certain RDF triples. The future Formal Specification at the W3C, specifies exactly which triples are assigned a specific meaning, and offers a definition of the meaning. OWL only provides a semantic interpretation for those parts of an RDF graph that instantiate the schema. Any additional RDF statements resulting in additional RDF triples are allowed, but OWL is silent on the semantic consequences of such additional triples. An OWL ontology is made up of several components, some of which are optional, and some of which may be repeated.

Using these Web-based standards as the jumping-off point for ontology and SOA, it's possible to define and automate the use of ontologies in both intra- and intercompany SOA domains. Domains made up of thousands of systems, all with their own semantic meanings, bound together in a common ontology that makes short work of SOA and defines a common semantic meaning of data. This, indeed, is the goal.

Extending from the languages, we have several libraries available for a variety of vertical domains, including financial services and e-Business. We also have many knowledge editors that now exist to support the creation of ontologies, as well as the use of natural-language processing methodologies.

In other words, we have a standards set of tools to define, manage, and share application semantics from domain to domain, including from the enterprise to the Internet, and back. It's time we started to use them.

Posted by Dave Linthicum on November 16, 2006 05:53 AM

November 15, 2006 | Comments: (0)

Managing SOA Semantics Using Ontologies and Supporting W3C Standards..."Web 3.0?"

First of all this "semantic week" thing is timely considering the hype the semantic web is getting this week now that somebody linked it to "Web 3.0." No, I am not kidding.

From Nick Carr, who writes about a New York Times Article (can not be pulled up without registration, so screw that).

"Web 3.0. Formerly known as the semantic web, but now rebranded for mass consumption, Web 3.0 promises yet another Internet revolution. It would, Markoff writes, 'provide the foundation for systems that can reason in a human fashion ... In its current state, the Web is often described as being in the Lego phase, with all of its different parts capable of connecting to one another. Those who envision the next phase, Web 3.0, see it as an era when machines will start to do seemingly intelligent things.'"

If you want to see a ton of hype in the making, just Google "semantic web and Web 3.0," and you'll see that both the Web 2.0 and SOA bloggers are alive and kicking about this "new concept."

Truth be told, I've been linking the semantic web to SOA for a long time. Just to name three times, you can go here, here, and even here, all written in 2003 and 2004, many presentations as well, typically at user group conferences. Not to mention this blog.

To be honest, however, not a lot of people cared until now. I knew it was going to be a big deal sooner or later. Semantics are just too important to too many things, and everything when you consider them in the context of application integration and SOA.

So, what is the Semantic Web?

From Wikipedia:

"The Semantic Web is a project that intends to create a universal medium for information exchange by putting documents with computer-processable meaning (semantics) on the World Wide Web. Currently under the direction of the Web's creator, Tim Berners-Lee of the World Wide Web Consortium, the Semantic Web extends the Web through the use of standards, markup languages and related processing tools."

So, if you're looking to manage semantics in the context of a SOA, what tools and standards do you have at your disposal here?

The Semantic Web uses XML, XML Schema, RDF, RDF Schema and OWL.

XML Schema is a language for restricting the structure of XML documents.

RDF is a simple data model for referring to objects ("resources") and how they are related. An RDF-based model can be represented in XML syntax (more on this tomorrow).

RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a semantics for generalization-hierarchies of such properties and classes.

OWL adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality, richer typing of properties, characteristics of properties (e.g. symmetry), and enumerated classes.

We'll touch on RDF, OWL, and more on the semantic web and SOA tomorrow.

Posted by Dave Linthicum on November 15, 2006 05:48 AM

November 14, 2006 | Comments: (0)

"5 Surefire Ways to Make Your SOA a Success" SOA Executive Form Presentation...As Promised

As promised in the Podcast, here is the "5 Surefire Ways to Make Your SOA a Success" presentation.

Download file

Posted by Dave Linthicum on November 14, 2006 05:51 AM

November 14, 2006 | Comments: (0)

SOA White Papers Now On-Line

I have had many of you request some of the papers I've done over the years, and a few new ones. So, I've put some of them on-line. You can find them here.

Happy downloading.

Posted by Dave Linthicum on November 14, 2006 04:47 AM

November 14, 2006 | Comments: (0)

Recap of the SOA Executive Forum and Semantics

Download file

Posted by Dave Linthicum on November 14, 2006 04:36 AM

November 13, 2006 | Comments: (0)

Managing SOA Semantics Using Ontologies and Supporting W3C Standards...Part I

Hey, hey, what do you know...semantics and ontologies is making a comeback, and SOA is driving the push forward. If you've been following me, you know I'm a "semantics guy," and I think it's the jumping off point for EAI projects 10 years ago, and now SOA projects today. Indeed, there are many out there who agree with me right now...I just wish they said something when I was publishing articles about semantics/ontologies and SOA years ago. I remember the response from an editor one time..."this is boring stuff..can you write an article on Web services?" But, a good idea is a good idea, thus I keep pushing...and I'm glad others are joining in. Check out my predictions.

"Finally, in 2005 I think that ontologies will become more of a focus as larger organizations plan for a SOA. When dealing with SOA, as you know by now, we are dealing with much complexity. We have thousands of data elements that we have to track, hundreds of domains, and the need to map the differences. Moreover, with the added complexity of service oriented mechanisms, we are also tracking meta services as well, or behavior as well as information.
The notion of ontologies helps the SOA architect prepare generalizations that make the problem domain more understandable. In contrast to abstraction, generalization ignores many of the details and ends up with general ideas. Therefore, when generalizing, we start with a collection of types and analyze commonalities to generalize them."

Okay, I was off a year.

Thus, I'm going to make this semantics and "ontologies week" on my blog. Kind of like "Shark Week," but no sharks.

Many in the world of SOA have begun to adopt the notion of ontology (or the instances of ontology: ontologies). Ontology is a term borrowed from philosophy that refers to the science of describing the kinds of entities in the world and how they are related. Ontologies are important to SOA solutions because they provide a shared and common understanding of data (and, in some cases, services and processes) that exists within an SOA problem domain, and how to facilitate communication between people and information systems. By leveraging this concept we can organize and share enterprise information, as well as manage content and knowledge, which allows better interoperability and integration of inter- and intra-company information systems. We can also layer common ontologies within verticals, or domains with repeatable patterns.

When dealing with SOA, as you know by now, we are dealing with much complexity. The notion of ontologies helps the SOA architect prepare generalizations that make the problem domain more understandable. In contrast to abstraction, generalization ignores many of the details and ends up with general ideas. Therefore, when generalizing, we start with a collection of types and analyze commonalities to generalize them.

Clearly, semantic heterogeneity and divergence hinders the notion of generalization, and as commonalities of two entities are represented in semantically different ways, the differences are more difficult to see. Thus, ontological analysis clears the ground for generalization, making the properties of the entities much more clear. Indeed, ontological analysis for SOA encourages generalization.

Considering that statement, it's also clear that application independence of ontological models makes these applications candidates for reference models. We do this by stripping the applications of the semantic divergences that were introduced to satisfy their requirements, thus creating a common SOA foundation for use as the basis for an SOA project.

One of the benefits of leveraging ontologies is the fact that no matter where the information resides, we can understand and map information relevant to the SOA scenarios. Ontologies allow you to differentiate between resources, which is especially useful when those resources have redundant data (e.g., customer information in almost all enterprises). Thus, in order to make better sense of the data and represent the data in a meaningful way, terms defined in ontologies allow the SOA architects to fully understand the meaning and context of the information. Again, this is ontology's value within SOA.

When considering schemas, local to remote source or target systems, the application of ontologies are leveraged in order to define the meaning of the terms used in some domain. Although there are often some communication between a data model and the attributes, both schema and ontologies play key roles in SOA because of the importance of both semantics and data structures.

To gather information specific to an entity, we need to leverage different resources to identify individual entities, which vary widely from each physical information store. For example, when leveraging a relational database, entities are identified using keys (e.g., customer number). Within the various information systems, many different terms are used for attributes. The notion of ontologies, in this scenario, allows us to determine whether entities from different applications and databases are the same or noncrucial to fusing information.

Okay, off to the gym. Tomorrow, let's talk about the semantics Web and Web 2.0, Web 3.0, or whatever they are calling it these days.

Posted by Dave Linthicum on November 13, 2006 07:32 AM

November 12, 2006 | Comments: (0)

Open Source ESBs Have Emerged

I've always found open source to be a strange concept, I mean, why would you want the source code unless you're prepared to become a software product company? However, clearly this notion has gained interest in the past few years, and the SOA space has many players, including open source application servers, open source governance tools, and open source ESBs.

"Open source describes practices in production and development that promote access to the end product's source materials—typically, their source code. Some consider it as a philosophy, and others consider it as a pragmatic methodology."

According to Wikipedia.

"Before open source became widely adopted, developers and producers used a variety of phrases to describe the concept; the term open source gained popularity with the rise of the Internet and its enabling of diverse production models, communication paths, and interactive communities."

Okay, not sure get that. However, what is clear is that end users like buying software this way, and what's more it seems to be much less expensive than the same products sold in non-open source ways. I do get that, and that's what is really driving things here I think. I love it when technology companies do things just as well as the big guys, but charge much less.

I sat next to Dave Rosenburg, the CEO of MuleSource last week at the SOA Executive Forum, in the speaker's room. He and I were moderating panels at the same time, and he took me through is open source ESB product "Mule Platform."

See the Mule architecture here

Mule came on my radar screen when I was at Bridgewerx. I asked my guys to look at it for use within the appliance. I'm sure other SOA and Web 2.0 product companies had the same idea, with MuleSource or somebody else. Indeed, open source does make sense, almost always, if you're looking to make it part of your product because of the adaptability.

After looking at dozens of ESBs out there, both complex and simplistic, I think that Mule has all of the major features that many ESB technology buyers are looking for, and if you drink the open source Kool-Aid, than this product will be more compelling.

"Designed to support high-performance multi-protocol transactions, Mule can be used for system to system messaging, as transactional middleware, or as part of an application server. The extensible nature of the core Mule server, along with the open source code base, allows developers to maintain control of their infrastructure."

In essence mule is not looking to be soup-to-nuts, just the nuts, and if you don't like the nuts you can change the nuts. It's designed to work and play well with a variety of different technologies (See diagram below), and what's more, if the product does not meet your specific needs you can adapt it yourself. Indeed, you could consider Mule a developer's product. It can run within a transactional container, such as EJB, work with JMS, and coexist inside very different problem domains.

There are other open source ESBs, including offerings from Iona and Jitterbit.

A productive use of the 10 minutes or so I spent with Dave, I think.

Posted by Dave Linthicum on November 12, 2006 05:20 AM

November 09, 2006 | Comments: (0)

InfoWorld SOA Executive Forum...Day 2

More of the same on day 2 of the forum...great content. The best presentation of the day, I thought, was: "Leveraging SOA to Expand Customer Self Service and a Disbursed Mobile Workforce" by Carl Eberling, Vice President IT, CIO West Area, Verizon Wireless

"This session focuses on real examples at work today in Verizon Wireless. It will also review the evolution of the architecture it takes to support a broad based implementation of SOA. The discussion will also explore the myth that this effort comes at a great cost."

Real world experiences about how Verizon Wireless was evolving their architecture towards SOA, and what they found. I thought Carl's explanation about how they extend their SOA to the wireless workforce was most informative. Moreover, how to build SOAs when the budgets are not unlimited.

After that was my panel on Composite Applications:

"Breakout Session: Business Real-World Composite Applications
The fruit of SOA is the ability to rapidly develop applications with existing services using a framework business analysts can understand. Four customers demonstrate how they built the necessary platform and are reaping the benefits. Moderator:
David Linthicum, Senior Contributing Editor, InfoWorld
Panelists:

Rich Colton, Application Integration Manager, Washington Group International
Pramod Mathur, Technology Programs Director, Lawson Software
Steve Octaviano, CTO, Palisades Technology Partners
Hong Lou, Associate Director for Application Technology, Partners HealthCare System"

I thought the panelists did a great job in describing their early work with composite applications, and how it relates to their core business. Basically, the concept of composites is here, it's useful, and was we move into the future it's going to become even more valuable. Great session...just wish I had more time.

On to my final session on "5 Sure Fire Ways to Make Your SOA a Success. I was pleased at the feedback I got from that presentation which was at the worst time in a conference to do it (not InfoWorld's fault, I had scheduling issues).

Enjoyed the conference, looking forward to next time. I'm attaching a few pictures below.

Posted by Dave Linthicum on November 9, 2006 04:51 AM

November 08, 2006 | Comments: (0)

InfoWorld SOA Executive Forum...Day 1

Yesterday I did make it to the Summit at about 11:00, and sat in a few sessions before having to get on e-mail and this blog. The conference is well attended with over 900 people here, and to think they just got things going 8 weeks ago.

The agenda is here.

The best session of the day was: SOA Meets M&A. The presenter was Neal Ruskin, Chief Enterprise Architect, Applications, TD Ameritrade. Just very candid about his issues and that goes a long way to be creditable as well as helpful for the attendees.

Last night I did attend the CTO dinner sponsored by InfoWorld (see photo). I typically don't go to these things at conferences opting for the local bars and restaurants as a break from the conference, but I did attend this one and I was glad I did. Good discussion around the notion of SOA, and it's relevance in future conferences, as well as the next generation of ideas about what will be cool next.

I was taken back by somebody putting forth the fact that the hype curve of SOA was fading, and that in 2007 or 2008, SOA would not be as relevant. While I do a agree there is a hype curve with any notion, and the hype can't last forever, the concept of SOA is more complex and far reaching and it's going to take years to get it right within the enterprises. We may not hear as much about it in 3 years, but it will still be a core discipline needed within most enterprises...mark my word.

Good dinner, good day, back to it today for the 2nd and final day.

CTO Dinner.JPG

Posted by Dave Linthicum on November 8, 2006 04:50 AM

November 07, 2006 | Comments: (0)

"Old School SOA" Still Making the Cut?

Download file

Posted by Dave Linthicum on November 7, 2006 05:28 AM

November 06, 2006 | Comments: (0)

Part 2: "Old School SOA" Still Not Making the Cut?

So, continuing from our discussion yesterday (okay today, but I'm traveling tomorrow)... how do you fix issues with "traditional integration" companies moving towards the SOA marketplace? Here are a few general notions.

New market, new approaches. As many of the more primitive middleware guys (message queue, RPCs, IPCs, etc.) found out when EAI emerged some time ago, it was not enough to position their technology in that space, even add some rudimentary enhancements. You really need to completely reinvent the company, and the technology around the unique needs of this new space. This means investment in time, money, and people, and that may mean taking down EPS for a bit, but in the long run you'll have a much more valuable asset.

Splurge on talent. Everyone has good ideas, but instantiating those ideas into compelling products takes very smart, independent, and innovative people who are not afraid to work very hard. Those people seem to be moving to the smaller SOA up-starts these days, and you need to do what you can to recruit and retain them. I could do more with a team of 10 kick ass engineers and product managers than 50 mediocre people, for instance, in my days as CTO.

Lead thought. Okay, everyone thinks they are leading thought by publishing white papers and doing Webinars, but that's just marketing and selling. Leading thought means you come up with more innovative ideas than your competition, and you can articulate those ideas so everyone understands how cool those ideas are, and can define the value to the business. Stated another way, you are able to convince the marketplace that indeed these are innovative ideas, and you provide products and services that live up to the proposed value. Not easy, but it can be done.

Walk in your customer's shoes. To many times I see technology companies who have great technology, but can't link it to their customer's pain points. Thus, they don't understand their customer's issues, really, and can't provide a true solution, just some technology that may or may not fit. Big mistake. You need to understand your marketplace (the general), as well as the problems you're solving (the particular). In many instances, SOA technology companies rush a solution to the market, with little understanding of how that solution will be "used in a sentence," or the solution patterns they are bringing to problem patterns. In short, understand your customer's needs, and align your technology and solutions with those needs.

Did I mention my new gig?

Posted by Dave Linthicum on November 6, 2006 12:10 PM

November 06, 2006 | Comments: (0)

Part 1: "Old School SOA: Still Not Making the Cut?

Okay, this is for SOA technology companies, end users need not read further, unless you want to learn more about this side of the market.

There is a Blockbuster Video near me, which I've visited many times in the past, as well as paid many late fees, and have been frustrated when the movie I wanted to see was not in stock. Along came NetFlix and I've never been in that Blockbuster since, or any Blockbuster or video store for that matter. Last week I noticed that my Blockbuster was replaced with a Panera. Panera has free WiFi by the way, now I can sit in there and order more movies from NetFlix where my Blockbuster used to be. I love irony.

So, what happened? Again, an existing business did not see a new wave coming, and did not react and retool in time to catch a change in usage patterns. Same can be said about the "traditional integration" companies out there selling SOA solution, many who are having a hard time capturing a raging SOA marketplace.

I've blogged about this before; even dedicated a Podcast to it, but it's worth visiting again based on the number of people from the "Old School SOA" camps that are reaching out to me seeking advice. In essence, the market is up, SOA is booming, but the "traditional integration" guys don't seem to be taking advantage of it.

So why?

First of all, let's consider the market. While there are many of these types of data points, here are a few:

"IDC estimates that $2.3 billion was spent worldwide on total Web services software in 2004, more than double the amount from the previous year. IDC expects spending to continue to increase dramatically over the next 5 years, reaching approximately $14.9 billion by 2009."

"According to Evans Data Corp's latest Web Services Development Survey, this year the percentage of functioning Service-Oriented Architectures (SOAs) has almost doubled. Web Services are now also experiencing more comprehensive implementation with thirty percent of respondents using more than 20-services in the next year, a 58% increase from today."

You get the idea, so the market is there. So, what types of technologies are they employing? In essence, they are leveraging the really really big SOA players. Or, they are buying from a collection of well funded up-starts, selling SOA design, governance, security, ESBs, or orchestration technology, in short taking a best of breed approach, leveraging the smaller more innovative players. By the way, some of these up-starts are now parts of the really really big SOA players, after the acquisition-mania that's been occurring in the last few years.

Often left out are the mid-tier SOA players, typically "traditional EAI" or application integration companies that indeed have sound technology and many customers, but can't seem to get their marketing messages and technology to line up the sales they need in this emerging space. In many instances the traditional guys are taking older, but more sound and tested integration technology to the new space of SOA, and still unable to get the traction they expect.

So, how do you fix it? I'll tell you tomorrow, okay later today, when I get back form the gym.

By the way, new gig: www.linthicumgroup.com

Posted by Dave Linthicum on November 6, 2006 08:17 AM

November 03, 2006 | Comments: (0)

The SOA Methodology Refinement Continues...Step X: Understand all services available in your domain.

Okay, now I'm moving from understanding data/semantics, to understanding existing or legacy services. You can see the old work here.

Understand all Services in your Domain.jpg

Services are very different. Some services are more behavior-oriented and some are more information-oriented, but all must be understood. Services differ greatly from application to application, custom or proprietary. What's more, many interfaces, despite what the application vendors or developers may claim, are not really service interfaces at all, and you need to know the difference. Services provide behavior as well as information, thus they are service-oriented.

So, using the metadata gathering in the previous step, as well as analyzing existing services, see need to devote time to validating assumptions about services, including:

- Where they exist.
- The purpose of the service.
- Information bound to the service.
- Dependencies (e.g., if it’s a composite service).
- Security issues.

This should include: Service analysis, service and metadata analysis, and performance analysis. Performance analysis should be done to understand if there are performance issues with the use of these services. Thus far, I've not found a SOA problem domain where performance was not a core concern.

The best place to begin with service is with the creation of a "candidate services directory." As with other directories, this is a repository for gathered information about available services, along with the documentation for each service, including what it does, information passed to a service, information coming from a service, etc.. This directory is used--along with the now-understood application semantics--to define the points of integration within all systems in the domain.

More later...

Posted by Dave Linthicum on November 3, 2006 06:01 AM

November 01, 2006 | Comments: (0)

Notes from the SOA for eGovernment Forum...Ontologies, Ontologies, Ontologies

I was asked the speak at the SOA for eGovernment Forum yesterday, hosted at the Mitre facility in McLean VA. I could not attend the first day, but I did attend the later half of the second day, including a few presentations on SOA approaches for the government.

I was most surprised at the number of presentations speaking about ontologies and semantics in relation to SOA. This is something I've been advocating for years, including back in the EAI days, but really did not pick up too many followers. Perhaps they need solutions that are more rudimentary, and were not ready for the notion of ontologies with is a tad complex.

Indeed, as I say about once a day, you have to have a semantic understanding of your problem domain before you attempt to build a SOA. The ontology approaches seem to make the most sense as we understand the data, and create data abstraction layers as well.

So, what are ontologies?

At its essence, ontology is a conceptual information model. Ontologies describe things that exist in a problem domain. This includes properties, concepts, and rules, and how they relate one to another, supporting a standard reference model for information integration (the link to application integration), as well as knowledge sharing. We are leveraging ontologies in the science of application integration and SOA since they support human understanding of information. This use is self-explanatory within the context of application integration and SOA.

Ontologies also provide the ability to facilitate information-based access, and information integration across very different information systems. We are able to achieve this by formalizing the application semantics between intra- and inter-organizational information resources.

I think they fit in the world of SOA, I'm glad others are beginning to agree.

Posted by Dave Linthicum on November 1, 2006 06:03 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •

•

• Archive •

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert