Showing posts with label soa. Show all posts
Showing posts with label soa. Show all posts

Thursday, April 29, 2010

Video Blogs on Impact 2010 Sessions Next Week

Are you heading to IBM Software Impact 2010 next week? I hope so!

I will be presenting on WebSphere XML Strategy. I will be presenting a session on the WebSphere Application Server Feature Pack for XML talking about usage scenarios, how to use the feature pack, and best practices (Sessions 1635A/B on Monday and repeat Thursday). I will also be providing a general education session on XPath 2.0, XSLT 2.0 and XQuery 1.0 (Session 1634 on Tuesday) focused on basic education as well as noting whats new with the standards - with a cool give away! I will be assisting a lab where you can get hands on experience with the XML Feature Pack and the Rational Application Developer tools (Session 1606 on Monday). Stop by any of these session or hit me up on twitter (@aspyker) if you have any questions about XML or data strategy within your enterprise.

Along with the XML Feature Pack and XML strategy talks, I'll be participating in a SOA and BPM Performance update (1321) talking about SPEC SOA and multiple panel discussions around the values of the application server, performance, and feature packs.

You can hear me talk about the sessions here:



Some other videos about sessions next week are available as well.

Erik Kristiansen on RESTful, dynamic scripting, and OSGi programming models:



Lan Vuong on extreme transaction processing and elastic application architectures:

Monday, October 12, 2009

In the news .. SPEC SOA benchmark effort

I wanted to shared some press coverage of the effort I mentioned back in September.

The original SPEC press release press release talked about how the work group was looking for participation, what the initial focus was on, and the unique challenges of producing a SOA benchmark.

In coverage by SearchSOA and TechTarget, the working group has been asked very interesting questions. The SearchSOA article talks about how SPEC is a good organization to take on the challenge of a SOA benchmark given its past track record in JEE middleware benchmarking and talks about the challenges of benchmarking typical implications of a service oriented architectures. The TechWorld article talks adds discussion of how the benchmark is focused on some core aspects of SOA but will likely grow over time and discusses how the benchmark will need to consider both IT and business requirements on typical SOA applications.

Also, the effort has been covered by TheServerSide and InfoQ.

As mentioned in the original press release, if your organization can contribute to the effort, contact info@spec.org

Also, kind of fun to see your quotes translated into various languages - Japanese, German for example. I do think this level of coverage indicates the value this benchmark will deliver to both technical and business communities.

Wednesday, September 9, 2009

SPEC working on standard SOA Benchmark

I continue to be interested in helping customers understand the performance of Service Oriented Architect (SOA) applications. As you can see here, I'm working (as the chair) in this SPEC working group, along with considerable input from Oracle and VMware on pushing forward on a standard benchmark for SOA based applications and the middleware infrastructure on which they run.

The interesting parts (in my opinion) of this press release are:

The benchmark will be developed by a trusted benchmarking organization with input from all SPEC members. Also, as mentioned in the press release, we're looking for participation by other interested parties. If you're interested in joining SPEC or providing input, let Bob Cramblitt know. I'm truly excited to see a SOA benchmark come from SPEC as they have a proven track record in creating industry trusted benchmarks for middleware performance.

While the initial focus is Web Services, Enterprise Service Buses, and Business Process Management (BPEL), the group realizes these technologies are only part of the entire SOA picture. It's good to see the group start with a sensible core and grow the effort over time.

The group is working to stay flexible on its support of multiple approaches to implementing these technologies. This is key, as SOA is an architectural approach and there are multiple ways to implement such technologies. However, in an industry standard benchmark it's important to audit and standardize common implementations to confirm they would be used in typical customer implementations.

I'll continue to post publically shareable information as the work group makes progress. If you have any quick questions, post them here and I'll ask them at the working group.

Monday, August 10, 2009

Another reason for DataPower SOA appliances - XML Threat Protection

I've gotten a few questions on recent XML security buzz. On today's blog post by Rich Salz (lead architect of our appliances) discussed how XML threat protection is a required tool when exposing important services to untrusted sources. He talked about this due to the recent press interest in "XML Exploits" which was started by some XML fuzzing work by Codenomicon.

I wanted to post about it here to make sure this wasn't an unknown concept to our customers. Rich talks about "defense in depth", which is what most of our WebSphere customers are doing today. To quote Keys Botzum (one of our lead security consultants for WebSphere, "Anyone that is exposing services to untrusted sources absolutely needs to be running a XML firewall, like DataPower)". In my world, defense in depth means putting a WebSphere DataPower XML Security Gateway XS40 in front of any services that could be called by untrusted sources. Also, given the performance characteristics of the DataPower devices (basically no latency impact), you likely want to do this on all services (as sometimes hacks aren't intention and sometimes hacks come from internal sources).

If you haven't heard of XML firewalls or XML threat protection, think about network firewalls. Network firewalls are great for protecting us from threats that can be detected at the network level (like the recent Twitter and FaceBook distributed denial of service attacks), but they don't help you with threats that are in the payloads of messages themselves. XML Firewalls help you with such application level threats by turning away bad messages before they enter your enterprise applications.

If you have any questions on the concept, feel free to pop over to Rich's blog and ask.

Saturday, November 8, 2008

More information on the TPC SOA benchmark

As I mentioned previously, the TPC (Transaction Processing Performance Council) is looking at SOA benchmarking. SearchDataCenter.com has an article that summarizes alot of the new and upcoming TPC work. You will see the TPC chairman, Mike Molloy, talk about the popular existing TPC benchmarks (TPC-C, TPC-E, TPC-H, and TPC-App) as well as new benchmarking efforts around energy (consumption with focus on greening of the data center), virtualization (across all new workloads), ETL (Database Extract, Transform, Load), and SOA.

On SOA, Mike explains, "TPC's SOA benchmark is only in the proposal stage, but the tentative plan is to focus on common industry-accepted portions of SOA infrastructure, mainly Web services, the enterprise service bus, and business process choreography. As advanced SOA practices become more standard in the industry, TPC will expand the benchmark to incorporate additional SOA infrastructural services".

I'm excited to work within the TPC to continue driving this SOA performance benchmark to reality. There are no other standard benchmarks that tackle these common SOA infrastructural components. If you have interest in seeing such a benchmark or comments on how it would help you, please post a comment. I'll relay them back to the TPC.

Friday, July 11, 2008

The TPC is working on a SOA Benchmark proposal submitted by IBM

Given the comments I made previously on SOA benchmarking, I'm happy to report that the Transaction Processing Performance Council (TPC) has agreed to evaluate an SOA benchmark proposal submitted by IBM. You can see in the recent "Meet the TPC" working session, the TPC discussed the TPC SOA workgroup on page 8. The summary is rather high level - "Tasked to evaluate SOA benchmark proposal from IBM". I believe if this proposal is accepted with modifications by other TPC participants, customers of SOA solutions and the industry can truly benefit from the TPC's standards-based benchmarking experience and levels of customer trust. I personally will be working to make this workgroup a success, with the intent of making SOA performance as understood as hardware, database, and J2EE performance. If there are companies out there with SOA solutions, I would personally encourage them to join the TPC and participate in this or other benchmarks and workgroups. I hope to, in the future, blog about the success of this workgroup and benchmark.

Wednesday, December 26, 2007

WebSphere Process Server and ESB 6.1 Available

The 6.1 versions WebSphere Process Server, Enterprise Service Bus, and Integration Developer are available for download from passport advantage. I personally have used the 6.1 version for both our internal SOA benchmarks and a recent ESB project. I can attest for major functional improvements -- I wouldn't use anything less than 6.1 for ESB projects. Also, since this moved the underlying application server to WebSphere Application Server 6.1 and Java 1.5, there are some major performance improvements in this release. Oh, and WebSphere Integration Developer is now based on Eclipse 3.2.2 which enables far more of my eclipse plugins to work along with Integration Developer.

Links to more info:

WebSphere Process Server 6.1 new features

WebSphere Enterprise Service Bus 6.1 new features
WebSphere Integration Developer 6.1 new features

Enjoy!

Monday, September 24, 2007

Perspective in Benchmarks - My thoughts on Microsoft StockTrader

I wanted to take the time to respond to claims coming from Microsoft. On June 4th, Greg Leake, Technical Marketing Manager for .NET of Microsoft started to discuss an effort with which he was involved. The effort was “porting” IBM’s WebSphere Performance Sample – Trade 6.1 to Microsoft .NET 3.0. Since then, Microsoft has been interviewed by trade press, has created video podcasts, and has started discussions on Microsoft forums and other development community sites. Please do not be fooled by these marketing statements.

In my opinion, Microsoft uses their report to focus on three points

- Attempt to prove that Microsoft is interoperable with WebSphere software
- Attempt to prove Microsoft’s SOA relevancy and readiness for the enterprise
- Attempt to prove Microsoft performance is better than WebSphere software performance

I’d like to state up front that I was personally involved with the development of IBM’s Trade benchmark starting with Trade 3 and ending with Trade 6.1. Others on my team have made significant contributions to the code as well to ensure that Trade continues to be an credible and useful tool to express performance concepts and release to release enhancements to IBM customers for J2EE (Java EE) programming.

Some level of interoperability

I applaud any effort by Microsoft or any other software vendor in pursuit of interoperability. However, the interoperability the Microsoft report speaks to is basic web services functionality (SOAP/WSDL/XML) only. It does not focus on interoperability of transactions, security, reliability, durability and does not use industry standard schemas that many of our customers need for cross enterprise (B2B) or intra-enterprise web services interoperability with .NET clients calling WebSphere servers. Independent of the Microsoft report, Microsoft and IBM have already focused on interoperability of these higher value qualities of service in Web Services through industry standard WS-I efforts as shown here and here. I am very happy to see IBM and Microsoft continue to focus on standards based interoperability. I am confident that WS-I will continue to facilitate customer focused web services interoperability in these higher value web service functionalities.

Is Microsoft enterprise ready?

Press coverage has cited the Microsoft report as helping Microsoft prove it is ready for the enterprise. From our quick look at Microsoft code, this doesn’t seem to be the case. Many of the “enterprise ready” features stressed by the Microsoft report are hand coded into the application. Areas such as multiple vendor database support, load balancing, high availability, scalability, and enterprise wide configuration for services contribute to the significantly higher lines of code count in the Microsoft application as compared to the WebSphere implementation. You should equate higher lines of code count to more maintenance and support costs long term and think about the value of this being provided in the application server product versus in the application itself. Some of the increased lines of code are for comments, but the comments themselves point out how many places where Microsoft deviated from using framework classes and instead implemented custom extensions to fill in gaps of functionality lacking in their framework.

As an author of Trade, I must admit an embarrassing fact. Four years ago, my team added web services capability to Trade as an optional component – to demonstrate web services as an alternative to remote stateless session bean methods. Since that time, I personally have worked hand in hand with many enterprise customers adopting web services. We have found that the Trade approach to web services wasn’t the best. Specifically the fine grained “services” in Trade average around 400-800 bytes of passed data. As you’ll see in my recent blog post, industry standard schemas for B2B typically have much larger payloads. While Trade was a fun exercise for my team to learn web services, it in no way mirrors what we know now our customers have told us are good web service practices. Current SOA principles motivate more coarse gained services. The embarrassing fact is that we never have gotten around to removing the poor examples of web services usage from Trade. However, it is interesting to note that Microsoft did not recognize or point out the obvious flaws in these web service patterns during their analysis – they merely parroted what they saw.

Microsoft entitled this paper as “Service Oriented”. Later in the press, Microsoft alludes to this “Service Oriented” benchmark test to help draw credibility to Microsoft’s SOA strategy. Based on what I just said about Trade web services, you’ll see why IBM has never talked about Trade and web services to help customers understand web service performance. Meanwhile, this Microsoft report focuses on these trivial payload web services to prove they can support “Service Oriented” benchmarks. Follow-up posts and press coverage followed the “Service Oriented” title, proclaiming that this in some way helps Microsoft’s SOA strategy. Drawing that conclusion is incorrect. The industry agrees that SOA is more than trivial web services. SOA is about a business centric IT architecture that provides for a more agile and flexible IT support of business needs. Realistic web service usage is a cornerstone of SOA, but web services alone do not define SOA.

Is Microsoft performance better than WebSphere performance?

I believe Microsoft is trying to draw IBM out of our commitment to standard benchmarking organizations to confuse customers about performance. You can draw your own conclusions from specific comments apparently made by Greg Leake in press coverage, asking for IBM to “collaborate”. Some have commented correctly on community discussions that the Microsoft report isn’t specific enough in terms of topology, hardware, and tuning to make any sensible conclusions based on the performance data. It is a compelling story that this Microsoft report weaves – Microsoft beating IBM on its own benchmark. However, IBM didn’t run Trade as a benchmark in the way shown in the paper’s results. As a customer, you should always be careful how much you trust proprietary benchmark results produced by a single vendor. These things can always be coerced to create FUD and confusion.

We have reviewed the paper and results and found inconsistencies with the best practices for how to run WebSphere Application Server. Assuming items Microsoft chose not to document along with improvements in performance allowed by following best practices, we in fact believe that IBM WebSphere Application Server would win across all the scenarios shown in the results.

You may well ask, if WebSphere Application Server would win, why wouldn’t you say so and publish a contrary IBM report. I don’t believe publishing a proprietary view of performance would help our customers – for all the reasons stated above. At best, if IBM was to respond to this paper, you could expect both vendors to degrade to the lowest common coding styles for implementing the benchmark so they would “win”. As shown already by Microsoft’s implementation, Microsoft wouldn’t choose to use their framework classes and features, but instead code optimal patterns in the application code. When those patterns are not tested and supported by the formal product, no customer wins by seeing the resulting performance.

IBM has a history of competing in standard benchmarking organizations such as SPEC. We do so because such organizations are standards based and unbiased and therefore trusted. Standards-based benchmarking processes give all participating vendors equal opportunity to review run rules, implementation code, and the results of other vendors. Given this, if you find Trade and SOA benchmarks useful, maybe it is time for IBM and Microsoft to jointly propose a SOA benchmark to a standard benchmarking organization. SOA benchmarking under standard benchmarking organizations is where our customers and the industry can truly benefit.

Summary

I personally talk to many customers about performance, SOA, and web services. I stand behind all that I say technically independent of marketing. I build strong long lasting relationships with these customers, many of whom know me personally. In good faith, I can stand in front of them with results from a standards benchmarking organization. I can stand in front of them showing our SOA leadership based on both customer references and analyst reports. On the other hand, I cannot in good faith show a one-off competitive benchmark run by a single vendor. I hope you can understand this position and it helps you discuss the coverage of this Microsoft report and any similar efforts by any vendor that follow.

This Microsoft report shows basic levels of interoperability and work within the WS-I shows higher levels of interoperability. The Microsoft report points out that Microsoft has to hand code many enterprise ready features that are just taken care of for you in WebSphere technology. The title of this Microsoft report and its follow-on press coverage attempts to confuse the industry on SOA, which points out how desperate Microsoft is to get press coverage in SOA. This Microsoft report doesn’t do a good job of showing the true performance story. Specifically on performance, I encourage all customers to put their trust in standard benchmarking organizations

Tuesday, September 11, 2007

New Redbook with SOA customer case study

A new Redbook has been published called "Implementing and Testing SOA on IBM System z: A Real Customer Case".

The Redbook does a good job of breaking down SOA implementation into a series of logical decisions, with real world implications. It covers not only the overall architecture, but the steps to get there. The final solution includes much of the WebSphere Business Process Modeling stack, including WebSphere Application Server, WebSphere Process Server, and WebSphere Portal, as well as tooling from WebSphere Integration Developer and WebSphere Business Modeler.

In particular, the Redbook shows how the SOA solutions fit into the existing ecosystem at the customer shop. SOA is evolutionary, not rip-and-replace. A good read.

Friday, August 24, 2007

SOA certification program launched

Just saw this article on the CNN/Money website.
IBM Federal SOA Institute Launches IT Certification Program: IBM today announced the first Service Oriented Architecture (SOA) certification and training program for Federal IT professionals. The program was established to provide knowledge, and share important skill sets needed, for SOA development and adoption.

The 12-week certification program is sponsored by the IBM Federal SOA Institute, and will begin September 12th through December 4th. A second series is scheduled for Spring 2008.

Two distinct course tracks are available: an entry level curriculum in order to become a certified SOA Associate, intended for those who are new to SOA concepts and would like to increase their overall understanding; and an advanced curriculum, to become a certified SOA Solution Designer, structured for senior IT professionals who require enhanced knowledge to deploy SOA capabilities within their organization.

Certification modules cover issues such as the value of SOA, determining return on investment, bridging the gap between technical and business teams, basic architecture, establishing solutions using existing assets and new components, identifying barriers to adoption, preparing for governance issues, and effective deployment and management within an organization.

More...


Tuesday, July 24, 2007

Obligatory First Post from Andrew Spyker

Terry invited me to join the community. I plan to get busy posting as much as I can, but I thought I'd start with an intro post. Someone beat me with a stick if I don't post within a week with real content.

I have been with IBM WebSphere Application Server for the past five years as a lead of our performance team. My time in performance has given me time to focus on many things - J2EE, Java, Security, Web Services, and more recently all things relating to our SOA foundation. Earlier this year I was promoted to STSM (Senior Technical Staff Member) and asked to broaden this focus more formally as a SOA Runtime Architect. This means I get to focus on more than performance (which I have traditionally done since performance allows you to experience all aspects of the product end-to-end) and more than WAS (ie. the rest of the SOA foundation). My focus as of late is how we can drive our XML strategy forward in both function and performance given XML is one of the core building blocks of all of our SOA runtimes. Also, I still advise the team I've built in WAS performance on daily basis. More on all of that later.

So in the end you should see a mix of content on XML, SOA, and performance from me.

Thursday, June 14, 2007

Multi-Cores, SOA, SCA and the Incredible Lightness of Being

I received a link from a colleague regarding a recent article "SCA applies SOA principles to Apps Design" by Andy Dornan. The article starts off with a slant that SCA enables runtimes to take advantage of multi-core CPUs; further implying that while Moore's law still is applicable for making the processors themselves faster, that the real leverage in software gains comes from building applications that can have multi-core processors thrown at them. He theorizes that in order to really leverage the multi-core processor future, that applications must be broken up into small loosely-coupled components. And this was just the first paragraph.

Whoa. Where to start. I can say the article made me think, does SOA, or SCA for that matter really help applications deal with multi-core processors? Far be it for me to criticize semantic English, but multi-core processors imply same-box, and the focus of SOA and SCA relate to the wider, distributed network; which may be comprised of multi-core processor nodes. Certainly SOA does help application developers in arriving at application patterns and best practices that lend themselves to being advantaged by multi-core processors, or even more importantly a set of distributed processes and processors. Simply using container-based applications like JEE or even Spring put the majority of the burden of thread management in the hands of the middleware, where presumably there are appropriate controls and exploitation of multi-core processors have been meticulously built; that really doesn't have much to do with SOA or SCA. Billy Newport has blogged numerous times about applications and multi-core issues as well. While there has been lots of research in predictive instruction execution and pipelining, SCA offers more like a circuit board assembly than a flow chart (perhaps like BPEL) and its model doesn't really imply any ordering or sequencing which would afford any great advance in multi-tasking. Certainly SCA has asynchronous invocation concepts which would allow for a greater opportunity for muli-tasking, but I would hardly say they are transparent to the application.

To cut Andy a break, perhaps what he intends to say is the SOA and SCA programming style of providing declarative dependencies and policies allow the runtimes to better understand the application and therefore, de facto have a better chance of exploiting the hardware available to solve the problem.

The article then diverges into other topic areas for which I also have some comments.
  • Java is certainly an important language for SCA to embrace and to treat in a first class manner, but it is hardly the only language. Certainly at least BEA and IBM and keenly interested in SCA assemblies with BPEL implementations, but there is lots of activity in other languages. Of course WebSphere is going to focus on Java -- it is a Java runtime. What will be interesting is how vendors choose to slice and dice the type of component implementations they support and in what form factor they will deliver that support.
  • I didn't quite understand his comments about requiring a higher-level intermediary to embrace WCF components. Certainly WCF components can consume or be exposed as Web Services, using WSDL and XML for interface definitions -- SCA embraces both service consumers and providers. Perhaps I'm missing some other point Andy is trying to make. Certainly, as I've blogged about before, SCA embraces existing (legacy) technology and I don't understand why anything would have to be rewritten. This seems just wrong to me.
  • I don't agree with the statement that the vendors believe SCA is needed to achieve "tru(e) platform independence." What SCA allows you to do is to compose and assemble applications written in a variety of implementation languages, hosted on a variety of platforms and insulates the business logic developer from having to have unnecessary knowledge of these implementations.
  • Microsoft is not interested in application portability, so certainly aspects of SCA are not interesting to them; however, the author does seem to be unaware that SCA, albeit in its original proprietary, has been shipping in WebSphere Process Server 6.0 for some time now.
  • Service Data Object is not an optional subset of SCA. SDO is orthogonal to SCA, but is rather complementary... to be honest, I just don't know what Andy was trying to articulate in his closing paragraph about SDO.
At the end of the day, I suppose its nice to see some articles coming out regarding SCA.... even if the ideas in the articles, I can't get my head around.

Friday, June 1, 2007

It really is Christmas Early... or is that Holiday Season?

Hot off the presses, a refresh of the latest externally available beta drop of the SOA Feature Pack for WebSphere V6.1 is available here. This feature pack leverages the Apache Tuscany open source technology from the Apache Incubator project to provide an implementation of the published Service Component Architecture (SCA) and Service Data Object (SDO) specifications implemented at by the OSOA Collaboration of vendors.
If you haven't heard of SCA and SDO, where have you been? :-) We are very interested in getting feedback on what we are doing right, but especially what we are doing wrong with these new SOA related programming and assembly model concepts.

Happy Coding...

Steve Kinder

p.s. I forgot to mention that the SOA Feature Pack installation also installs the Web Service Feature Pack, as we base our Web Service support on the new AXIS-2 runtime. If you happen to download the SOA Feature Pack, you get both feature packs.

Wednesday, May 30, 2007

SO-UH... IT SOA Part 4. No, really separation of concerns.

From the previous blog site, I've had 3 entries on exploring why the SOA vision isn't really hard -- not to be confused with the reality in the industry -- which is nonetheless quite difficult to sort through. At any rate, so far I've stated that Service Orientation is important because it gives the industry a common approach to develop, design and speak of distributed applications; that in order to be successful, SOA principles must at its heart embrace our existing technology; and that finally, a greater level of flexibility can be achieved by ensuring that our service consumers and our service providers have a level of independence -- an appropriate level of separation of concerns, such that provider implementations can be changed with independence from and of the consumers.

To really achieve a separation of concerns between the service consumer and service provider, it is often beneficial to introduce the concept of service virtualization. Service virtualization is the concept that we don't actually publish the concrete service provider to consumers, we publish an intermediary which exposes the formal service interface and business contract. In its simplest form, the intermediary is really just a pass-thru which merely passes parameters and context to the real, concrete service provider implementation. In more complicated forms, dynamic decisions can be added to the intermediary to choose the most appropriate service provider implementation. A very simple business example is the famous "getStockQuote" service. Some stock quotes are delayed 20 minutes but are free to obtain; whereas real time quotes usually cost the consumer a small fee to obtain. Both provide the same service, one has a greater expense to the business, but better quality of service. This intermediary is sometimes called a mediation.

Service virtualization is one of several beneficial aspects of Enterprise Service Bus patterns.

Bottomline: Separation of concerns is a good thing to build flexible, agile applications. Best practices and newer programming constructs can achieve a good deal of separation of concerns. Service virtualization complements these concepts, and extends separation of concerns to older programming styles, patterns, languages. Service virtualization facilitates us embracing legacy applications, utilizing them where they are hosted.

Steve Kinder

Friday, May 25, 2007

Darryl K. Taft comments on IMPACT 2007

Darryl K. Taft at eWeek has a new article called "IBM Shows Impact of SOA". Excerpt:

Steve Mills, senior vice president, IBM Software, in a statement, said that "SOA has been a growth engine for IBM, as well as our customers, because it gives companies the much-needed flexibility to focus on achieving business results without being hindered by the constructs of established infrastructures. IBM's differentiation is in its ability to address business challenges using the right balance of business and technical skills along with an unmatched, multipronged approach to meeting customers' needs."

Mills also said he sees the worlds of Web 2.0 and SOA coming together to offer new opportunities for both vendors and users.

"We're bringing the people impact into the picture and leveraging things like RSS and Atom," Mills said. Web 2.0 technologies are bringing more usability, "consumability" and user-driven content into the equation, he said.

It's interesting to me that both Sandy Carter's book and Steve Mills' statement tied together SOA and Web 2.0. At first glance, it seems like the only thing they have in common is that they both are big buzzwords... and hey, why use one buzzword when you can use TWO! But looking a little deeper, I think in some ways Web 2.0 technologies are doing a great job of delivering SOA, particularly with regard to mashups. Stitching together a quick mashup using a bunch of existing services is very SOA. It also shows very clearly that SOA is not a technology offering. It's a way of doing business. Whether you use AJAX and JSON or EJB3 and web services, you can choose to architect your solutions using SOA principles.




Musings about Sandy's Carter's new SOA book

From a user experience standpoint, I'm a "true believer" when it comes to SOA. I think SOA is exactly the right approach to make real world improvements in the amount of complexity that users need to consume in order to be productive. And I use those words very carefully, because I am of the school of thought that "complexity" is a zero-sum game. Those of us in user experience never eliminate complexity, we just move it around. SOA gives us an architecture to move around complexity in a more efficient manner, so that users can be productive in their particular job without needing to understand the complexity of the entire ecosystem.

So when I picked up Sandy Carter's new book, "The New Language of Business: SOA & Web 2.0", I was interested to see if she would touch on this perspective. Clearly, SOA is a vast topic that can be tackled from many different angles, so there was no guarantee that user experience would be touched at all.

Naturally, given her background, Sandy focuses on the business side of the SOA equation. She hammers home the points that being flexible and responsive requires an alignment of business needs and IT needs, and neither can do the job by themselves. In addition, she makes it clear that this is nothing new... from Henry Ford to McDonald's, flexibility, responsiveness, and efficiency have always been of major concern to enterprises. What has changed now is the tools available to take this to the next level, such as standards-based technology to make interoperability an assumption rather than a herculean effort. In particular, I enjoyed the case studies that described how real companies were adopting and benefiting from SOA approaches (including IBM). The one thing that stood out in these case studies was their diversity. Every company approached SOA differently, based on their business needs, their IT skills and architecture, and their process maturity. This is yet another reason why I appreciate SOA (and IBM in general) -- we don't try to claim that there are one-size-fits-all solutions to any of the problems facing enterprise customers today. And Sandy clearly did not try to make SOA appear easier than it really is.

But what about user experience? I'm happy to say that the book touched on user experience topics in several places, though it wasn't a major theme. When it was mentioned, she tended to focus on the user experience of the end user, rather than the implementers. Again, this is not surprising given that the focus of the book is about the business justification for going to a SOA architecture, and clearly one of those benefits is to allow customers to create a more seamless experience for their end users. For example, here's an excerpt from one of the case studies:

Standard Life group of companies Plc, headquartered in Edinburgh in the U.K., has become one of the world's leading financial services companies. The majority of Standard Life group of companies' business and revenue is generated through independent financial advisors (IFAs) that help their customers select financial and insurance products from a number of different assurance companies. many IFAs utilize industry-sponsored portals to obtain product information, compare prices from multiple providers, and provide a single view of a customer's holdings.

Standard Life group of companies realized that, to remain competitive, it needed to offer its IFAs easier, more flexible, and quicker online access to its financial information. Standard Life group of companies also needed to reduce the cost of doing business with multiple business channels. By reducing its costs, not only could it improve its bottom line, but it also could improve its competitive standing and its relationships with its IFAs; more self-service and quicker processes via automation could help the IFAs improve their margins.

This is a message repeated in several places throughout the book - that SOA techniques can allow our customers to provide a better user experience for their customers. But I would also add that SOA can provide a better user experience for IBM's middleware customers as well, namely because it will allow them to pick and choose who in their organization is capable of handling the most complexity, and architecting their solutions accordingly.