Real World SOA | David Linthicum | September 2007

MORE ENTRIES

September 2007

September 27, 2007 | Comments: (0)

That whole VDA thing is starting to pick up steam, including this post by Jonathan Kahn who provides some very elegant analysis of my assertions.

"In Zapthink's recent article about avoiding Vendor Driven Architectures, David Linthicum makes the case that choosing one vendor for your enterprise's SOA needs is perilous and potentially costly. While this caution bell rings soundly, it appears that today most enterprises may have little choice but to turn to their chosen vendors. Once this process has been started by an inquiry, there is a tendency to march down a very rigid, pre-defined sales process in a winner-take-all battle of wit, determination and even (dare I mention it) discount-wielding (usually in the form of multi-product bundle discounts and 'free' support). Sound familiar, oh yeah, I bet it does."

The notion of VDA is really something most enterprise architects understand far too well these days. However, enterprise architects really work from experience and thus the narrower their experiences the more likely VDA will occur. Indeed, if there is anything that bugs me about this business it's the number of enterprise architects out there that don't' focus on the core business problems, and don't learn to align technology to the business, SOA or not. I'm finding that is another level of maturation that many have just not reached yet, and the core businesses are absorbing millions of dollars in lost productivity considering that the architectures (SOA) are more tactically oriented, thus static, vendor driven (VDA), and thus difficult to change around the needs of business.

"All the various pressures to produce with a fast-food style delivery, the architecture blueprints that would ordinarily take patience, devotion and painstaking process to distill into meaning, forces us down a deterministic path of Product Platform Selection or (worse still,) Presumed Business Requirements. Increased urgency to IT alignment and buzzwords like "agility" in the business climate only serve to accelerate the decomposition of even the most seasoned IT Architect's resolve and diminish the most confident practitioner's integrity in the unbiased practice of their art. Adding to the challenge are the growing list of skills, certifications and aptitudes that some of the recent Executive Architect-seeking clients we've been working on, seem to consider as pre-requisites."

So, how does one fix this? Education is key here along with admitting you have a vendor addiction and getting help. I can just see 20 architects sitting on a room, all in a circle…"My name is John Smith, and I'm have a vendor addition." The first step is always the hardest…SOA is something you do guys.

Posted by Dave Linthicum on September 27, 2007 05:08 AM

September 26, 2007 | Comments: (0)

Leveraging an On-Demand Platform for Enterprise Architecture

I typically don't plug my Webinars here, but there is a very interesting one I'm doing on Thursday (tomorrow)…Leveraging an On-Demand Platform for Enterprise Architecture. This is an essence the talk I gave at Dream Force last week in San Francisco. I've gotten some good feedback from that one.

What's cool about this the paradigm shift. While I've been an advocate for integration on-demand (e.g., my past gigs at Grand Central and BRIDGEWERX), applications on-demand, the notion of a platform on-demand has only recently come to life with the stuff that Salesforce.com has been working on. So, tune into this one. It's going to be more education than a "sell job."

Posted by Dave Linthicum on September 26, 2007 07:14 PM

September 25, 2007 | Comments: (0)

Time to Do Things Over, but Not Do Them Right?

Many companies balk at enterprise architecture because they feel that the returns doesn't necessarily justify the investment, but then again, most companies have never really done enterprise architecture before nor do they know how to really invest or do it right. But that's a theme for a different blog post.

Rather the issue is many companies feel that they can continue doing what they are doing now and do architecture at some point in the future. In essence, they are saying that there's no time (or money) to do things right now, but there's time to do it over and over again.

If you think about that, it doesn't make any sense. Why would a company have time to do things right in the future if it's just digging the hole deeper? The answer is typically spun around budget issues, and even office politics.

The connection is that on Thursday, this is one of the key issues we're discussing at our Practical SOA for Financial Services event in London, and will be a recurring theme for all our sessions. It's not sufficient to know about SOA, but companies have to know to do things right before they just go back and do things over.

The truth is that delaying "the fix" just costs more money. More than you think, when you do the analysis. I'm constantly surprised how much is wasted around ineffective and static architectures that are not able meet the needs of business. The solution is complex, but with a bit of work doable, within most organizations. You just have to have the desire to fix things once and for all.

Posted by Dave Linthicum on September 25, 2007 08:48 PM

September 24, 2007 | Comments: (0)

Thinking SOA

Download file

Posted by Dave Linthicum on September 24, 2007 07:26 PM

September 23, 2007 | Comments: (0)

AJAX and SOA…

AJAX has set the world on fire when you're considering creating a Web-delivered dynamic application, or what many call a RIA (rich internet application). With AJAX World occurring this week (which I'm not attending by the way), I figured it's time to look at the links between AJAX and SOA once again…drilling down a bit deeper this time.

We use AJAX other RIA development environments for several different reasons:

Leverage dynamic behavior at the user interface. This means supporting the dynamic user interaction that most thick clients provide. Now we're moving the "thick" functionality to Web clients. These clients should be able to provide windowing features and data navigation controls such as check boxes, buttons, radio buttons, toggles, dialogs, menus, etc. Moreover, a RIA needs to provide rich-media component objects such as animated sprites, multi-track sound and video.

Loosely couple the presentation layer and logic layer. Thus, each RIA interface is changeable without also changing the back-end services, and changes to back-end services won't necessarily drive changes to the clients. This loose coupling saves a bunch of development time and money if designed and deployed correctly.

Provide both connected and unconnected modes of usage. This means that the clients may or may not be connected to the back-end services. Users can work in situations where network connections are not available, such as at client sites or on airplanes. This is a core feature needed for supporting mobile devices, such as cell phones, laptops and personal digital assistants. The RIA interacts with the back-end services when connected but is able to continue functioning when not connected, perhaps queuing up requests.

Improve integration for data residing locally and remotely. Traditional thin clients cannot easily integrate data that resides locally. RIAs overcome this limitation by processing on the client. Moreover, RIAs can reach out and talk to any data source, local or remote, using the interface, not the back end, as the point of processing. This is more like the traditional client/server model and offers a flexible architecture.

As SOA becomes more of a standard way of looking at architecture, many are seeking new standards-oriented interfaces that are able to externalize services to user interfaces, in many instances, on the platform for the Web.

AJAX tools seem to fit the bill nicely, and many are more oriented towards SOA than others. Most recently, I took a look at SmartClient from Isomorphic Software. What I like about this tool is that they work from the data, up to the processes, logic, and the interface. Call me "old school", but working from the data up seems more logical and natural to me, especially when considering how SOAs are built…from the data up to the services, and then the processes, typically.

Of course, SmartClient is not the only AJAX game in town, there are dozens of development tools to choose from, all with different approaches, and intended uses. However, when thinking about SOA you need to consider how these tools will provide a loosely coupled framework for your architecture, and enabling services for human interaction. Most development tools will work, but AJAX seems to provide the path of least resistance when it comes to SOA.

Posted by Dave Linthicum on September 23, 2007 06:03 PM

September 18, 2007 | Comments: (0)

Are you doing VDA for SOA?

Download file

Posted by Dave Linthicum on September 18, 2007 07:44 AM

September 17, 2007 | Comments: (0)

Thinking SOA…

There seems to be a lot of confusion when it comes to traditional enterprise architecture and SOA. So, while many argue revolution, I ague assimilation and enhancement. This means that SOA provides a core systemic value to enterprise architecture, and thus it's difficult to separate the two notions. Moreover, those that are successful with these concepts learn quickly how to think SOA.

While many of you are nodding your head right now believing what I say is true, there are more enterprise architects out there that don't really get SOA (and don't read this blog), and have yet to begin to think SOA. This is going to lead to many enterprises not finding the value within IT that they need, and their management demands.

So, how do you think SOA? It's really a matter of thinking more about interoperable components, not layers and layers of technology. It's really about thinking agility, and not just a technology solution instance. In other words, thinking SOA may need to leverage a different side of your brain when coming from a more traditional world. In my keynotes this Fall, I hope to make a lot of noise about that notion. Hopefully, I'll convert a few.

The core issue is that we do what we know, and those who have been doing traditional enterprise architecture for years always fall back on their knowledge of models, frameworks, and the management concepts around enterprise architecture. Can't blame them, really.

However, SOA is a different way of thinking about systems development, governance, testing, configuration, and even information. While the core components may still be present, the way that these components interoperate, using services, is going to have some new and valuable patterns. Now is the time to figure out what's new, how to leverage these notions, and learn how to do SOA right, and make it systemic to your enterprise architecture.

So, change your brain.

Posted by Dave Linthicum on September 17, 2007 04:37 PM

September 15, 2007 | Comments: (0)

Avoid VDA! (Vendor Driven Architecture)

When looking at the technology buying patterns in the world of SOA, there is one common thread. The Global 2000, and many government agencies, are purchasing from their existing vendors, no matter what the needs or requirements. I call these solutions purchasing "comfort technologies" since their considering the relationship with the vendor more so than the value of the technology itself. It's comforting to deal with the same company, people, and platform.

Moreover, many of these same companies working with "comfort technologies" are also allowing the vendors to design and define their solution. I call these vendor driven architectures, or VDAs, but they are always called a bad idea if you understand the core issues.

The core problem is that the vendor is not a disinterested third party. They are there to sell technology, so no matter what your requirements are; their technology will meet the need. Chances are, your requirements are not given proper consideration and, chances are, the technology solution is not optimal for your problem domain or enterprise. Moreover, chances are you're paying a bit too much $ for the SOA solution versus a best-of-breed approach.

Don't fall into this trap. While vendors are good people, and want to make you successful, they are not responsible, nor should they be, with your core SOA. They are brought into the mix only after you understand your own issues, and only after all possible technology solutions have been considered. While they may know a lot of about SOA, it's in the context of their own stuff, so don't be fooled that you're getting objective advice. This includes certification courses offered by vendors. Drive your own needs, and leverage independent outside assistance to validate your work, or help you through the process.

Hopefully you'll find that the "comfort technology" is the proper technology. For now, I fear that many companies and government agencies are not going through the proper steps to insure that their solution will provide maximum value. I have a feeling that this blog post will be emailed throughout organizations that are making the same mistakes.

Tell me about your VDA story. dave@zapthink.com.

Posted by Dave Linthicum on September 15, 2007 05:08 AM

September 13, 2007 | Comments: (0)

Could Lack of SOA Drive Shareholder Lawsuits?

The failure of many major corporations a few years ago, which drove a bunch of new compliance laws and shareholder lawsuits, could also be leading to the reality that shareholders are looking at enterprise architecture efficiencies, along with accounting and reporting practices.

At issue is the fact that many major public companies don't have efficient enterprise architectures, and thus the business is unable to adapt to new market opportunities, reuse key IT assets, and thus not provide the maximum return to shareholders. Therefore shareholders have a large stake in existing enterprise architectures, and those that are still static and inflexible, due to a lack of proper strategic planning and use of technology (e.g., SOA), could find themselves explaining their enterprise architecture issues during depositions, not at technology conferences.

Those that own stock in a major corporation assume that the IT departments, and thus the architects, are doing their level best to make sure that the architecture is optimal for the business. However, in many cases, that's not true. Years and years of neglect, and in many instances lack of talent and understanding have created enterprise architectures that look like dysfunctional super highways within the enterprise, with so many layers of complexity, and so much fragility, that the business is unable to integrate easily with new partners, stand up portals, provide customer services, and other key business processes that are needed to make the business efficient and revenue generating in a timely manner. In many instances, it takes months to change major business processes, and as such, IT is hindering the success of the company. In essence, years and years of poor planning and bad architecture has created an IT infrastructure that is hindering the corporations ability to make money, thus return value to shareholders, thus could drive lawsuits.

While SOA is often pushed as a fix for poor enterprise architecture, the truth is that many companies are just purchasing ESBs or application servers, bolting them on, and calling it day. By doing that you're actually making the architecture worse by making it more complex. Needed, is a long term cogent SOA strategy that includes breaking the current architecture down to its component parts, and building it up again as something that is much more efficient, and thus revenue generating. SOA is something you do, not something you buy. It's complex, hard, but worth it if you do it correctly.

So, considering that some companies don't have good enterprise architectures, and therefore they are not optimized to return value to the shareholders, and are not doing SOA or doing SOA properly, the shareholders my take aim at IT asking that a complete audit be done on the methods and practices in building an effective enterprise architecture, and ask key questions that many IT organizations would not want to answer.

I suspect this is going to become more of an issue in 2008, as some organizations that get SOA are able to return provable value to the shareholders, and those that don't get SOA, are not. Moreover, those that fail at SOA are even in worse shape, since they have actually gone backwards in some instances, spending money and just adding complexity.

The moral of this story is to get your architecture right now, else deal with angry shareholders and boards of directors that will find other people that can do it for you.

Posted by Dave Linthicum on September 13, 2007 05:21 AM

September 11, 2007 | Comments: (0)

More Data Points about SOA Productivity and Value

Download file

Posted by Dave Linthicum on September 11, 2007 04:19 AM

September 10, 2007 | Comments: (0)

Things that Most People Misunderstand About SOAs

As I go from conference to conference speaking on the development of SOAs I'm always surprise to hear how much people don't understand about this concept. Perhaps it is the marketing engines around the many vendors grabbing land in this space, or perhaps it's how SOAs are explained in the main stream IT press. No matter how you got it wrong, it's time to get it right.

Number One: Service-Oriented Architectures are a new concept.

Not really. We've been attempting to create solutions and technology around the notion of sharing functional behavior, or services, since we have had more than one computer running in an organization. Indeed, RPCs were the first real attempt at providing this type of architecture, then IPCs, and on to more sophisticated technology such as distributed objects like COM and CORBA. Web services, albeit a newer standard approach, work much like "traditional" distributed objects. In other words, it's an evolution not a revolution.

Number Two: You must use Web services to build a SOA.

Nope. While Web services are an enabling standard leveraged within many SOAs, you can certainly build SOAs using other standards-based technology such as CORBA, COM, J2EE, etc. You may even build SOAs using technology that's proprietary to you. Remember, SOA is an architecture. The technology you employ should be appropriate for your requirements, there is no one size fits all.

Number Three: If you purchase an ESB, you have a SOA.

Not really. ESBs are good technology, they allow you to move information in and between applications, and do so through Web service interfaces. However, they are one solution out of many, and you must first understand your own requirements and issues before buying one of these puppies. Thus, while they can certainly be part of some SOAs, they are not really a "SOA-in-a-Box" solution.

Number Four: SOAs are naturally highly scalable.

I'm sure most of you already knew this was a no. Indeed SOAs are an architectural approach. The degree in which they are able to scale is a function of the technology solution. For example, those that stand up services that are too fine grained may find that scalability is an issue as more of a load is placed on the architecture. There is no magic bullet when considering scalability. You have to first design the SOA correctly, understand the properties of all of the parts, and select the right enabling technology and development platforms. This issue is a book unto itself.

Number Five: SOAs are always justified.

In many cases you can make a business case for SOAs because they address two issues which save many organizations money, including; reuse of existing software (as services), and the ability to change the IT solution as the business needs change, or agility. You must do an assessment before you setoff to design and build a SOA, and do a business case based on your understanding of the benefits and the cost of the project. In most cases the cost is justified, meaning it will make the company money, but in some cases it's not. Remember to factor in the soft savings as well, such as the agility a SOA brings to an enterprise, and the enterprises' ability to adapt IT to new markets quickly.

Number Six: You have to use a single vendor when building a SOA.

Many point to compatibility issues when dealing with a number of vendors. However, the fact is no one vendor has an end-to-end solution for all architectures, and requirements. Thus, typically if you pick a single "big stack" vendor solution, you're only getting part of the architecture right. Unfortunately, it's a bit more complicated than just picking up the phone and buying from the major vendor already in your company. However, based on what I'm seeing, many are purchasing technology that way.

Number Seven: When building a SOA you select a type of technology and vendor, and work from there.

My god no. You understand your requirements, what problem(s) you're looking to solve first. Do a business case, and then design your system. This means doing a bunch of work including understanding the semantics, security issues, integrity, services that already exist, and services you'll need to create, etc., etc., etc. Then, and only then talk technology, and don't forget the proof of concept testing to validate the technology before writing the check.

Posted by Dave Linthicum on September 10, 2007 06:38 PM

September 07, 2007 | Comments: (0)

When Services Attack

Lately, I've been hearing about some nightmares when considering bad service design. They fall into three basic problem areas:

First, services that are too course grained, and thus are basically cumbersome applications until themselves, not services. We'll call that one the "Fat Service" problem. Developers are asked the reuse this beast, and can't really find a use for it since it is an all-or-nothing proposition, providing too much bulk for a single service. How would you like to deal with a service called General_Ledger? This issue has typically be caused by developers that learned early on that course grained services…good…fine grained services…bad. That's not always the case.

Second, and as you guessed, are services that are too fine grained, decomposed to nothing, and do a very good job in saturating the network as very heavy HTTP calls are made (of course, you don't have to use Web services). We can call this the "Skinny Service" problem. I think the developers actually had good intensions here, but just go carried away, assuming that thousands of services can plug into a composite, and it will all be good. It won't.

Finally, poorly designed services, or services that perhaps are the right weight, neither fat, nor skinny, but the way the service is structured leaves a lot to be desired. Poorly designed interfaces are the bulk of the issues that I see, as well as services that are, well, not built like services. The end result is something that needs to be redone from scratch, going through a good service design process, re-implemented, and tested. We'll call this the "Ugly Service" problem.

So, what's a service builder to do? It's really not complicated. Services contain certain patterns that should be considered during design. I'll hit upon those patterns in the future. I hope your services are never fat, skinny, or ugly.

Posted by Dave Linthicum on September 7, 2007 11:18 AM

September 06, 2007 | Comments: (0)

ZapThinking Now!

First of all, sorry for the lack of blogging this week. It's been a rare week, and a short one with the holiday. I will be back to my old blogging self tomorrow, and will post a new Podcast on Monday night, as per normal.

Second, as many of you already know, my firm, the Linthicum Group, LLC, was acquired by ZapThink this week. I'm now a managing partner at Zap, working with the current ZapThinkers…Jason and Ron. Ron founded the firm back in 2000, Jason joined shortly after that.

You can read all about the acquisition here, but here are a few excerpts:

"ZapThink, LLC, the industry's foremost advisory firm focused on Service-Oriented Architecture (SOA) today announces the acquisition of The Linthicum Group, LLC, a well-respected SOA consulting firm, and the addition of David S. Linthicum to ZapThink. ZapThink will expand its intellectual property and team with expertise and resources from the acquisition to provide ZapThink customers with expert SOA advisory, research, and guidance. The announcement was made during Linthicum's keynote address to the e-Gov Institute's 7th Enterprise Architecture Conference & Exhibition in Washington, DC."

…which was yesterday. I meant to record it for the Podcast, but my Rio recorder would not work for some reason. The audience was great. I wish I could have stayed for the rest of the show.

"In addition to the Linthicum Group's well-respected and renowned work in the SOA and enterprise integration marketplaces, David Linthicum is a highly visible thought leader who is responsible for writing for and managing a number of significant blogs and publications, as well as speaking at hundreds of industry events over the course of his career."

Truth-be-told I've received a lot of offers in the last year, and I felt that ZapThink was the best fit. I've known Ron and Jason for years, and they are both "real world" guys who tell it like it is, like me. Thus, I suspect that we'll all have some good fun in the forthcoming years helping clients, educating the world on SOA, writing and speaking about SOA, and fighting the good fight as the SOA market takes off. I could not imagine doing anything else right now.

Posted by Dave Linthicum on September 6, 2007 02:07 PM

September 03, 2007 | Comments: (0)

No Podcast this Week

I'll pick it up next week, so stay tuned.

- Dave

Posted by Dave Linthicum on September 3, 2007 03:19 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •