The Grey Lines

Service Based Spaghetti (SBS)

2008-07-24T16:58:00.003-04:00

We started off with Distributed Spaghetti(DS). It was pretty bad. We had 100's of applications talking to each other using multiple protocols and no standard exchange format. Worse yet we really didn't know which apps were talking with which apps. It made maintenance and enhancements a lot of fun. Kind of like which brick do I pull out of this wall to make the whole thing collapse.

Then we moved on to Centralized Spaghetti (CS). The vendors came in with great new wares that promised to straighten out your noodles (don't even go there). Only problem was that there were some secrets on how to straighten your noodles and not everybody bothered to find them out. So we ended up with CS and then blamed the product and vendor.

But the best spaghetti was yet to come. The cool thing is nobody even knows it's spaghetti. Here the apps don't know their apps, they're called services. They still have to talk to each other but now they have a very special language. Turns out this special language is pretty complex. And you guessed it, not everyone bothers to learn it completely. Now we have promised our patrons a very elaborate 7 course meal that they can change to their whims right while it's being cooked. But as it turns out you still need cooks who know how to cook otherwise your back to the old standby, spaghetti. That's right, just about everyone knows how to make spaghetti. Raghu anyone?

So what's my point? Well it is a blog do I really have to have one? Okay here it is. Decent software design really hasn't changed that much in the past few years. Yes the technology is changing but the same old good software design principals have not. Encapsulation, abstraction, reuse blah blah blah have been around for a while now(granularity is a bit different). Please don't say SOA is different because it's about the business. If you have been producing software and architecture with total disregard for the business then you are probably seeking employment. If you were successful with OOP and EAI styles then SOA is not going to be a stretch. If you didn't do so well with those or didn't even attempt them then enjoy your Raghu, SBS style.

SOA Governance from MuleSource

2008-07-14T12:39:00.003-04:00

Joe McKendrick reported this from MuleSource. I think this is good news and worth a look at some point. Tools in this space tend to be pricey. It is nice to see something clearly aimed at a different customer segment. Lots of potential here I think. If I get a chance to take a closer look I'll post back the results of that at some point.

SOA Pitfalls

2008-07-08T06:43:00.002-04:00

Here is some actual useful information on SOA Pitfalls posted by the folks over at Xebia. This article is more for the actual designer and implementer of services. It has some very practical advice on service granularity as well as issues you run into when using a CIM. With all the high level stuff/fluff on SOA still leading the way, it's nice to see some practical information based upon actual experience implementing this stuff. This is very good and useful reading. If you are actually involved in implementing services then the issues and solutions in this series of articles should ring home.

Business Activity Monitoring

2008-07-03T18:19:00.002-04:00

One project I'm working on at the moment is using webMethod's Optimize for Process. It does BAM for processes. One feature of this product suite that I don't think webMethods does enough advertising on is it's ability to monitor external processes. This means you can send activity data to the BAM platform without using webMethods process engine runtime to manage your process. Basically any system or service that can invoke a web service can send data.

The really cool aspect of this is that you are able to map out your process using webMethods Designer and but then having it orchestrated or implemented by a completely different system(s). From the webMethods monitoring platform it still appears as a webMethods implemented process. If you are a webMethods customer, you should check out the functionality of the web service data collector that is part of the Optimize engine. It is extremely easy to use and features are very robust.

Just in! Progress Software buys itself!

2008-06-27T13:02:00.002-04:00

After buying up everything that was available, Progress Software has decided to buy itself in an unprecedented move according to industry analysts. After the acquisition is complete Progress plans to sell itself to Mindreef later this year which it now owns somehow creating a rip in the space time continuum.

On a lighter note, the North Pole is melting. This prompted Progress to announce that it would be buying the North Pole as soon as the ice has cleared out.

Great Apes Think Ahead: Conclusive Evidence Of Advanced Planning Capacities

2008-06-19T09:12:00.002-04:00

Maybe we should study them a little more especially our folks in Washington, DC. From the article

by using self-control and imagining future events

So who is more advanced?

Security - LifeLock Article

2008-06-12T10:18:00.003-04:00

Here is a very good and objective article on LifeLock by Bruce Schneier. There are a couple of reasons it's good. First, Bruce did some homework to help present facts versus perceptions. That's enough to want to read it by itself. Second, it's interesting. We have all seen the commercial with the CEO's SSN number on the truck. Haven't you wondered if that was real?

Not to get to deep into politics but Bruce has some good points on lobbyist and our government (for those of you in the US). We are very focused on the upcoming presidential election here in America but the reality is the real power is in congress and with the lobbyist(in this case the banks). I think regardless of who wins the presidential race, a lot of folks are going to be disappointed a couple of years down the road when they realize nothing has really changed.

Service Design and Reuse

2008-06-06T18:34:00.002-04:00

Coarse grain versus fine grain services. That was a big debate when SOA first raised it's head. A couple of years later I'm seeing a lot of discussion on reuse or the lack there of in SOA. I am wondering if folks are deploying really coarse grain services and trying to get the reuse at that level. Getting reuse out of a service that really does a lot is going to be very challenging.

My design approach over the past couple of years has been to focus on fine grain services. There is more potential for reuse at that level and in fact that is what has played out in my organizations. These services can also be connected to make a more sophisticated higher level service which tends to focus on a specific business problem and has limited reuse capability. There is nothing wrong with coarse grain services but expecting a lot of reuse is probably not realistic.

Another area which tends to limited reuse is your XML schema and WSDL design for those of you using the web services implementation approach. Putting to much of the validation effort into your XML schema can lead to a lot of rework for every new invocation of a service that has slightly different variation(also hampers interoperability). I have found it best not to put to much strain on the XML and leave more of the validation to the implementation. You could certainly argue that service versioning and multiple implementations of the service could solve that as well. Both ways have their merit. I would save the multiple implementation method for situations that require a significant change in the implementation(which should be the minority).

In the end you will have a mixed bag of coarse grain (few of these) and fine grain services. Most of the reuse potential is going to come from your fine grain services. If you are expecting your business analyst to dynamically weave together your coarse grains services as they see fit and when they see fit then you might have issues with reality that should be addressed with some sort of on-site SOA therapist.

ESB Bashing Continues

2008-05-31T06:27:00.003-04:00

I'm not sure what has started this latest round of ESB bashing but here is ZapThink's take on the ESB. I was okay with the article until I got to this part.

From ZapThink's Jason Bloomberg

In particular, it is essential to take a process-driven approach to your infrastructure, instead of an integration-centric approach. Remember that building Service compositions that implement processes typically compose capabilities across multiple execution environments. Furthermore, those compositions are both dynamic and unpredictable -- the business process specialist in charge of the compositions may change them around long after you've deployed the Services. Governance becomes the key to managing that unpredictability, rather than pre-defined integrations.

Business users creating dynamic composite unpredictable applications based upon services you have deployed. I think this is where SOA starts getting the Ivory Tower reputation. I really don't believe that 99.9% of organizations will or even should attempt to achieve this. I think before you propose something like that you should have some details on how you would accomplish it. Show how your service design could so flexible and robust to account for unknown variations on how it is composed without compromising your companies critical data and infrastructure.

My next issue came with this part.

One essential point here is that SOA leverages interoperability more so than portability. In a virtual machine-based "write once, run anywhere" environment, whether Java or Microsoft Common Language Runtime (CLR)-based, distributed computing relies upon the portability of code. SOA, however, leverages the interoperability of the Service interfaces so that you don't need to move the underlying Service implementations around. As a result, running all your Services on the ESB can actually impede your SOA implementation, rather than support it.

I don't disagree with a distributed service environment but again one size doesn't fit all. Managing a distributed service environment is not easy and in fact can also impede your SOA implementation. Extremely strong governance is a must in that type of environment. The fact is some organizations are better suited for a centralized bus approach and there is nothing wrong with that.

The last issue is on messaging. Here is the quote:

So, only use the traditional messaging middleware capabilities of your ESB if you really need them, and only leverage the Service runtime your ESB provides when convenient, but configure your ESB as an intermediary to get full value out of it as part of your SOA infrastructure.

There really isn't any detail here to explain the thought on why messaging is bad. Does it mean all messaging including SOAP based messages? Or is it just targeted at the built-in messaging most ESB's provide? Either way I don't follow. Messaging is very powerful and robust. Given the state of most Web Service development I have seen, more traditional messaging can be a powerful alternative. Remember that a service is not a technology specific thing, right?

The article also had a lot of strong points in my opinion. In particular this is a good quote to reiterate.

The bottom line is to always remember that the business drives the architecture, and the architecture drives the technology. Don't let the technology drive the architecture! SOA is particularly adept at abstracting existing technology, which can include recently purchased products in addition to your legacy environment. But knowing which of your existing capabilities to leverage -- and which to forego -- can make or break your SOA initiative.

IT has been known to go out and buy technology and then go looking for a problem to solve. To the point of the article knowing when to leverage your existing technology is very important. That can be an existing ESB though and that's okay.

SOA Implementation

2008-05-30T07:56:00.002-04:00

Since this blog is called the The Grey Lines I would be remiss if I didn't point out the greyness in Joe McKendrick's latest post on ESB's. I certainly understand where Joe is coming from but this is one of those grey areas. SOA is not about the technology, I think that has been beat to death by now. However developing a service and implementing it still requires technology. I'm doubting the enterprise in question chose the ESB route simply for the one project.

There is the belief out there in the distributed nature of an SOA style of implementing services ie location independence, technology agnostic etc etc. I don't disagree with that and designing services should certainly take that into account. However in the enterprise decisions have to be made on technology implementations. The fact is one size does not fit all. While one enterprise may go to distribution (very strong governance needed here) another may find a more centralized platform (governance still needed but not as strong) works better for them.

Decisions have to be made every day in the enterprise that involve compromise. It's just the nature of the beast. I think understanding how your own enterprise functions is a key to picking the right implementation strategies. I know most folks would say SOA is not about the implementation but ignoring it will lead to disappointment with your SOA style of architecture.

Service Versioning

2008-05-28T19:40:00.002-04:00

Todd Biske pointed out this article by Surekha Durvasula on service versioning. It's a good article and something to give some thought to. Believe it or not you will have the opportunity to have more than one slightly different implementation of the same service. It's not something I really bought into a while back but I have seen the value first hand.

There are some other low level reasons for versioning services as well which have to do with your schema design ie namespace management and your xml schemas. I'll return with more detail on that in a later post. XML schema design and Web Services is an area lacking in attention in my opinion. Doing it correctly is really the foundation of a good service.

Do you need a really expensive governance product to do service versioning? No not really. As long as you have a policy that is defined and manageable, you are on the right track.

New Blog

2008-05-27T11:47:00.002-04:00

I've retired the Darth.Net blog and started The Grey Lines. The main reason behind the move was to take advantage of more features that Blogger allows when hosting with them. Check out the poll on the right hand side of the screen.

What about the name? Well other than the ever increasing grey in my hair it really has more to do with discussing things that are not always black and white. I think most people would agree that the world and it's issues, both technology related and not, are not black and white. Surprising though I don't find reasonableness in opinions to be the norm anymore. It seems to be either side a or side b, wrong or right. It's as if we have made everything into a team sport with winners and losers. Take a look at our current American Presidential race if you don't believe me.

It's my hope that I can talk or have conversations about things (technology or not) that have caught my attention or interest in a way that is both objective and reasonable. How difficult is that to do? It's extremely difficult. I find it a constant challenge to be objective more often than not. Objectivity requires patience, mindfulness and letting go of the ego. These qualities are not always easy to come by. So let the experiment begin.

Experts: 'Indiana Jones' pure fiction - CNN.com

2008-05-13T13:34:00.000-04:00

Experts: 'Indiana Jones' pure fiction - CNN.com Okay everyone have the collective... duh. What would we do without experts. Well we apparently can't take a whip and pistol while raiding archaeological digs and shoot wrath of God beams out of the Arc of the Covenant.

Reminds me of some of the SOA experts telling us that it's about the business over and over again, duh..

Mainframe versus the cloud

2008-05-03T06:31:00.003-04:00

An interesting interview with an IBM guy on the role of the mainframe in business and the latest buzz on cloud computing. He has a lot of good points and most importantly his points are based in reality and not academic discussions. To summarize, the mainframe is still the key system in a lot of companies, this is especially true in financial companies (I can attest to that). The idea that these companies would move these systems off the mainframe and into some cloud of services located anywhere and hosted by anyone is completely ridiculous. That will be about the same adoption rate as companies moving to a successful SOA. :)

Some of his points are also not valid as well. Running programs in complete isolation is certainly possible on the mainframe but only if you have architected and setup it up that way. I've seen regions bring down regions because of some shared piece of hardware or pipes. As with anything the touted benefits are available if you actually know what you are doing.

I ultimately believe the mainframe will die a slow death as a couple of generations start leaving the workplace. The lack of skilled resources in that field has already started to have an impact. That being said it's replacement will probably not be the cloud. In the meantime it's alive and kicking so brush up on your green screen.

Woah on WOA

2008-04-26T07:40:00.003-04:00

Web Oriented Architecture is becoming the new academic discussion from the industry analysts. I feel like I was watching a TV show and someone changed the channel right when the good part was starting. What happened to SOA? We got it all figured out and time to move on to an implementation specific architecture? Just when we start to get the point driven in that services are not about the technology here comes WOA which is very much about the technology.

I don't really think WOA should be used in the same context as SOA. It's not the same thing or even related in my opinion. Using it in the same discussion context as SOA just confuses more an already confused bunch of IT people let alone the business. It may have it's place in the architecture tool box but it's only one tool.

Here is the thing I like about services. It doesn't matter what the underlying implementation is, where it is implemented, or how the services are wired together. It doesn't matter if they are on the external web, internal web, outsourced, Rest style, web service style etc etc etc. It just doesn't matter. If we implement those services a certain way and with a certain set of technologies, do we need another label for it? Does it really provide a value to have another label? I say nope.

What do you think? Is this more analyst mumbo jumbo or does WOA as a term and architecture actually provide value?

Spider Plague Closes Australian Hospital :: WRAL.com

2008-04-23T08:07:00.000-04:00

Spider Plague Closes Australian Hospital :: WRAL.com. Seems like something out of one of those B horror movies. Of course I did notice in the article that warm weather was to blame....which means this will end up being attributed to Global Warming. Just think, spiders will take over the earth in the next 50 years because we drive to much. Who would have ever made that link? Personally I'd rather go via a redback spider than drown in the rising sea. Of course this brings up another point, going green. If we go green and it actually reduces the earth's temperature, what impact will that have on the redback spiders? I'm sure the redbacks don't have an advocacy group yet but just wait.

It's the data

2008-04-19T06:59:00.002-04:00

I'm stating the obvious here but the underlying key element to services is the data. Agility, reuse, composibility and all that other jazz is difficult to achieve when you do not really understand the data. Chris Madrid has posted an article on Master Data Management over at SOA Magazine. I think Chris's points on the issues facing the enterprise are outlined very well. Multiple sources of the same or variations of the same data are the heart of the issue. Keeping them in sync and knowing which one to draw from can be difficult at best. The solution as outlined by Chris, is basically a central repository that serves as the master data. A very noble cause within the enterprise.

I think there are a few issues with this that some enterprises will run into. Does the enterprise actually have data architects? I going to throw out there that surprisingly few do. That can be a problem. Developers, DBA's and even Enterprise Architects don't always make for the best data architects. And even when they do understand it very well, it's usually not their primary focus. Moving to the Master Data Management concept requires resources that are focused on just that. This leads to the next issue which is buy in. Can you get the enterprise to agree on the concept and if so can you then get them to agree on the data model?

I don't think the issues facing Master Data Management are all that different from the concepts of a Common Information Model. It can be a large black hole for an enterprise. Attempting something like that a can turn into a long effort that ultimately doesn't keep pace with the changing business and is outdated before it's even put into place. I do agree with the concept though and I think the closer you can get to this state the more successful your SOA can be.

Red Hat bails on consumer Linux desktop | Tech news blog - CNET News.com

2008-04-17T10:27:00.000-04:00

Red Hat bails on consumer Linux desktop | Tech news blog - CNET News.com. I won't say I told you so but I told you so. That market is just to tough to crack without throwing tons of resources at it. Apple has that ability, Linux does not.

First PC? Or was it a MAC?

2008-04-16T10:15:00.001-04:00

It was 20 years ago today: Not Sgt. Pepper, but my PCjr | Coop's Corner : A Blog from Charlie Cooper - CNET News.com Charlie Cooper posted this entry on his first PC. It started me reminiscing about the old days. I had a Timex Sinclair ZX81. It was hooked up to a cassette recorder and a small portable TV. My first BASIC programs solved quadratic equations and graphed Sine waves. I thought that was very cool. My neighbor on the other hand, who was a year younger than me, had a TRS-80. He wrote a BASIC problem to automate his father's drug store. Just slightly different skill levels. :)

Practical Service Design

2008-04-12T07:23:00.006-04:00

One thing I've noticed over the last year is the continued lack of resources on detailed service design. There are plenty of resources geared at the architecture layer but very few geared toward the person actually doing the coding. I am hoping over the new few months to share some of my practical experience and pose some questions I still ponder on the details of service design. I'll also share some links on the Web that I have found to be useful.

If you do the actual design and implementation of services, please feel free to chime in with your own experiences. There is no one right way to do it. Good dialog on practices is always beneficial.

I'm in the middle of some major projects at work so I'm not sure when I'll get started. I want the content to be detailed and useful so it could take some time. In the meantime I'm very excited about the new book coming from Thomas Erl on Web Service Contract Design.

Linux PCs?

2008-04-02T12:46:00.001-04:00

Here is a story over on yahoo about the emerging Linux PC. I'm a big fan of Linux and Open Source software in general. However Linux on the average consumer's(that includes business users) desktop is just not going to happen other than in the niche its already in. The only vendor that has made any dent (small dent) in Microsoft's PC OS realm is Apple. You can make arguments all day long about the differences in the technology but it makes little to no difference.

It would be like your favorite local brew pub going against Anheuser-Busch. Of course I will look back on this in 10 years to see if I just completely missed the boat but somehow I don't think so.

Common Information Model

2008-03-30T09:17:00.003-04:00

The idea of a Common Information Model to rule all within a business has been around for a long time. It's gained a lot more traction recently with SOA. Here is a post from Nick Malick at Microsoft and some of their efforts. His post is part of an ongoing conversation with Alex Maclinovsky at Sun.

They both bring up good points but I find myself leaning towards Alex's realism a bit more. I can bring up the point that the average business IT shop does not have a lot of luxuries when it comes to time. CIM's take time... a lot of time. They also take knowledgeable data architects, expert negotiators and the ability to bend the space time continuum. Simply out of reach to most IT shops.

Would a large model that rules all hold up to the daily demands of the constantly changing business? I know the academic arguments around versioning, governance etc but that within itself can be difficult even with a governance product. By the way Microsoft has a new product in this space, only for MS products though. :(

I've stated before that one size doesn't fit all meaning what works for my organization might not work for yours. I have found that smaller simplistic data structures combined with more granular services can achieve a lot of flexibility and reuse. These can be wired together to make more coarse grained services but the reuse tends to go down and the complexity goes up.

Ultimately data translation and manipulation has to happen anyway to satisfy the needs of the off the shelve systems as well as old legacy systems. Some common simplistic data structures can help with that without having to go for the big bang approach that a CIM can create.

Upgrade Time

2008-03-28T12:29:00.002-04:00

My home server is in need of an upgrade/replacement. Here is a picture of it (Notice the cool steering wheel). I think my mobile phone has more RAM than it.

Home PC

It's served me well for the 100+ years its been around but I'm thinking time for a upgrade plus I'm getting tired of the black smoke coming out of it. Don't get me wrong the three laptops in the house have more than enough computing power for my everyday use. But the keeper of the blog needs a little more juice. Plus the OS it's running on needs a little upgrading as well.

I haven't decided what its new platform and OS will be, I'll have to do a little pondering on that. SUSE has served me well but I might want to shake it up a bit just for the grins of it. I'll keep you posted on my pondering.

How's SOA?

2008-03-24T18:44:00.004-04:00

This seems like a strange question since most field IT folks (not analysts) are still not really sure what SOA is or how to implement it. Is a year really long enough to give organizations time enough to get their stuff together? How many IT shops have the luxury of stopping time and focusing on changing the way they build applications? Isn't SOA really an iterative journey over a longer period of time? Todd Biske wrote a very good post on Setting SOA Expectations.

Todd was inspired by this post from Anne Thomas Manes who was looking for SOA success stories. Although Anne painted a pretty bleak picture I not sure enough time has past to call it a day and move on to the next set of buzz words. This quote from Anne in particular got me thinking:

This company reorganized IT around functional capabilities (rather than business units) and established strong positive and negative incentives that encourage people to adopt a better attitude toward sharing. I'm beginning to think that this is the only path to SOA success.

I not sure I would go along with this train of thought. The dynamics of a company, the personnel in the IT shop, the business landscape the company plays in, the size of the company are all factors that shape the way an IT shop functions. There is no one size fits all. What works for one organization is probably not going to work for another. Still I think there is potential value to be had on the road to an SOA style of architecture and the sharing of best practices. That doesn't mean all best practices will work for us or are required for us to derive value.

Okay my next post will be back to more technical in nature(XML Schema). I know you can hardly wait, XML Schema discussions make for such fun dinner conversation.

It's Back

2008-03-22T07:56:00.002-04:00

It's been a year since I shut down the blog. I'm finally starting to settle in at my new company so I thought it would be a good time to get going again with the blog. I can't believe a year has gone by so fast.

The IT shop is much smaller than my previous one but the intensity is much higher. I was brought in to jump start the webMethods practice and that's what we have done over the past year. I've spent most that time developing rather than architecting and it's been a blast. There is just something about being hands on that just can't be beat.

In addition to webMethods, I'm really focused on Web Services right now and in particular XML Schema design. Stay tuned for more on that.