Java and .Net Link

I find this project interesting but I question whether you would ever want to use it in a real production implementation. I'm trying to come up with a case where you would hook in down at this level from Java to .Net instead of at a higher service level. Why would you mix the two? If you have chosen Java over .Net I'm assuming maybe you are a Java shop. You might like the portability of Java. If you need stuff from Windows that only .Net can provide then why not just write it in .Net because it's not going to be portable at that point any way. This Java-.Net link seems complex and brittle to me. Cool but practical?

Go Naked!

After reading this article on Naked Objects in .Net I think it definitely supports the theory that there is good naked and bad naked. This would be bad naked.

I guess if you are an exceptional OO shop then maybe this is achievable but is it desirable? I'm not sure. It seems to be on the surface another example of over engineering.

SOA versus SOI

I read this post from Anne Thomas Manes about SOA and SOI. I have to disagree with the assessment. SOA does not have to be extremely disruptive to be started or to be successful. SOI, don't love another acronym, is a very good way for companies to actually get started down the SOA path without the major disruption.

Standards based integration with Services as the focal point can lead to the reduction of the very legacy systems Anne is talking about. If done correctly the plumbing can make the transition to SOA more fruitful and less impacting to the overall business. The idea you have to rip all the systems out and rewrite everything as a service is kind of far fetched.

One of the key issues with SOA adoption and success in my view is this kind of talk. It's the over engineering discussions that either paralyze an organization into inaction on the SOA front or cause an organization to go on some mass rip and replace tear that ultimately has very negative impacts.

Start simple, don't over engineer, don't go on a shopping spree, don't try to explain SOA to your business. Another massive IT project is probably the last thing your business needs right now.

Desperate Times

A couple of crooks steal a Salvation Army kettle. Crime always goes up during economic downturns as people become desperate. My online kettle is safe and goes directly to the Salvation Army. If you want to help the local Raleigh area Salvation Army or the national level, feel free to contribute $5, $10 or whatever you can spare to help out these people helping people. The bell is ringing.

Have a great holiday!

Thankful

For whatever reasons or no reason at all I have been extremely fortunate, blessed, lucky in my professional life as well as my family life. Over the past year I've seen more and more examples of hardships being faced by so many people here in the United States and all over the world.

This is of course nothing new, suffering has been around a long time. I guess for me personally it just seems more acute than it ever has before.

Over the past year I've been finding more and more ways to give back with what I have been so fortunate to receive. One of the organizations that I give to is the Salvation Army. I've started an online kettle this year. Here is the link .

If you subscribe to this feed you can follow the link or go to my blog's homepage and view the kettle along with it's progress. If you have a few extra dollars this year I encourage you to donate to whatever charity or organization you can. If you can spare a few to my online kettle that would be wonderful as well.

Thank you and I hope everyone has a wonderful holiday

New Books

Just done with Service Oriented Architecture with Java by Binildas Ca, Malhar Barai and Vincenzo Caselli. It's a good hands on type of book, lots of examples using Java. The book also does a good job of laying out service definitions and contrasting styles of architecture. I really liked their practical examples of hybrid contract design which is something we do. The one thing I didn't agree with was the contrast between EAI and SOA styles of architecture. But that's okay I usually don't agree with people's interpretation of EAI. It's not a big book so it's fairly quick to go through.

The other book that just arrived is Web Service Contract Design and Versioning by Thomas Erl and a slew of others. This book gets down into the details of contract design which is long overdue. I just got it so it will be a while before I can get through the whole thing. It's a really big book.

Event Processing

If you haven't already go visit Brenda Michelson posts on Event Processing. There is a lot of good information there, well worth the listen.

What or How? Is that really a SOA Discussion?

I've read this post from Todd Biske several times now. Todd makes some very good points about the technology debates going on with SOA discussions. The essence of the point is focus on what your are building as opposed to how you are building it. This supports the notion that SOA is about an architectural style rather than a specific platform or technology.

Although I agree with Todd's point about IT sitting at the table with the business to help decide what is being built, I'm not really sure that's a SOA discussion. SOA is an architectural style. Sitting down with the business to guide direction and what is being built is an age old issue. We use to call it IT/Business Alignment. As I have said before if you have been building solutions without good IT/Business communication going on then you have probably been outsourced. I don't think moving to a SOA style of architecture changes the need for IT to be at the table with the business helping guide direction.

I think the analogy of a surgeon is a good way to think about this. Your doctor consults with you about your health issues. Together you come up with a plan on how to deal with them. That plan may involve surgery at some point. At this point the "how" becomes very important. For a given surgery there may be multiple techniques that have various recovery times and impacts to a patient's lifestyle. Your surgeon's knowledge of the various techniques and their ability to perform them have a large impact on the success of the operation.

To me SOA is no different in that the diagnosis and the implementation of the procedure both have to have focus. One without the other is an incomplete solution. I definitely see Todd's point about sitting at the table with the business but you also need to make sure you have some good cooks in the kitchen when it's time to cook. Otherwise here comes that spaghetti again.

I think another important point about the "how" is that it's more than one piece. The "how" to me is not the technology selection you have chosen but rather "how" you implement that service on that technology selection. That "how" cannot be emphasized enough in my opinion. You can get the "what" completely correct but botch the "how" and be left with a mess. You have then failed to deliver on the promise of services.

Top 5 Uses for Google Earth

I was so inspired by this post on a great use of Google Earth I decided to come up with some other great uses of this technology. I know most of you have been struggling with how to leverage cloud computing and/or services hosted by external vendors. I'm here for you. Here's my top 5 uses.

5. Finding SOA. After all figuring out the oriented part is half the battle. Now you can know which way your SOA is oriented using hi-tech satellites. I believe the research will prove out that it's east/west instead of service. That would explain why so many here in the US are struggling with it. So that would be EOA and WOA(Don't confuse West Oriented Architecture with Web Oriented Architecture, this has nothing to do with spiders).

4. Finding the shortest lines at Disney World. I just got back and it would have been very helpful.

3. Finding Disney Land France. Apparently the British have no idea this exist and is just a train ride under the sea away.

2. Enforcing SOA Governance Policies. Yes by linking in the Google Earth satellite photos to our space based defense system you should now be able to fire a highly concentrated laser beam at wrongly oriented SOA implementations.

1. Cow Tipping of course. Now that you know where they are and which way they are facing it should be much easier.

Feel free to chime in with your own amazing uses of Google Earth. Please stay away from the mundane stuff like finding energy, fighting crime etc..

Extending Services

Here is a good example of taking an existing service and adding functionality to it without breaking the existing interface. Enjoy.

SOA in the wild

Is that a SOA in the freezer? Just substitute the acronym SOA everywhere you see Bigfoot in the article. The similarities are uncanny.

Runtime Discovery and Composition

Brenda Michelson put up this post from Melvin Greer about SOA and the "Hard Problems". It's good stuff especially this part from Melvin:

Within the engineering category, Mel spoke of altering existing development processes and methodologies for SOA, designing for context awareness, and designing for runtime discovery and composition. In respect to runtime discovery and composition, Lockheed Martin is trying to determine the best way for a running to composition to become aware of newly delivered capability. As an example, Mel called out how the Mars Land Rover continues to receive new capability without returning to earth

.

I must admit I have always been skeptical about runtime discovery and composition. I just haven't found a lot use cases that ever made sense. I just don't see this been very practical in the wild of the typical business. Now before you jump in, the programming of the Mars Rover is not normal business activity although way cool job.

Understanding the context of possible uses for services in different compositions seems amazingly challenging to me. Just getting services to be agile and reusable within known business context is very challenging. I certainly would like to hear more from folks who are exploring this space or have implemented solutions that would fit into this categorization. I thinking more along the lines of business type services not generic utility type services which can apply to any context. Anybody out there doing this?

Agility versus Reuse

Joe McKendrick wrote a post about CIO's and SOA. In the post he touch on a subject that is near and dear to me. Is the value proposition with SOA more slanted towards the agility it brings to the business or in reuse?

Architecting and coding for agility is nothing new. The principals behind it abstraction, loose coupling have been around for a while. Folks who have been in the OOP world or the EAI world know all about hiding the guts of the underlying implementation from the consumer. The better job you do at that the more agile your service, interface, object, message or whatever you want to call it, is. That's the technical side of agility, the other side is governance. Keeping the interfaces agile requires governance. That can get pretty difficult. The very benefit that the business tends to like about agile IT stuff can also make it very difficult to sustain.

The constant change associated with most businesses and the demand that places on the IT staff can make maintaining the agile infrastructure challenging to say the least. Without strong governance the agile interfaces quickly become very brittle. It is harder to design and code agile interfaces which means shortcuts tend to creep in as the business demands more change.

Reuse complicates the matter even more. Reuse requires picking the right level of granularity for the interfaces as well anticipating some degree of polymorphism across different domains of business. This generally requires a lot more effort during design time especially when moving from IT type services to more business oriented services. I have personally found this to be a significant challenge. It is challenging on two different levels, technical and business oriented.

The technical challenge lies in the both picking the right level of granularity for the services and developing reusable data structures to support this. I have generally found that the lower the granularity level is then more potential for reuse exist and the easier the design. You can always combine lower level services to move up the stack.

The business challenge is far more difficult in my opinion. Reuse especially across business domains requires a very good understanding of the business as well as a solid partnership with the business. This understanding and partnership is not at a high level but rather at a very detailed level for reuse design. Given the pace at which the business moves this can be very difficult to achieve.

I think keeping the interfaces agile and picking small battles for reuse makes some sense from a realism perspective. I have never been convinced completely that SOA would actually save money because of reuse. I do believe in the power of agile interfaces. No doubt that some folks will be successful with large scale reuse in the SOA space. I think for the masses however, achieving an agile infrastructure is a significant accomplishment that will pay dividends with some hard work of course.

Cuil it

That's really it in a nutshell. Cuil will never work because when you say Google it, you know exactly what the person means. When you say Cuil it, do you mean cool it or do you mean go find something. I say cool it to my 9 year old all the time, I also say Google it a lot as well. Especially during homework time. Cuil it will just cause way to much confusion. I'm already confused enough most of the time, I don't need this.

Pretty pictures though......

Service Based Spaghetti (SBS)

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

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

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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?

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

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

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?

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

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.