Thank You Zaxxon

Kindle 2 Review

2009-03-02T11:59:00.000-08:00

I received my Kindle 2 last Wednesday. This is my first experience with the Kindle product line or any electronic book product so I will not be able to compare it to any similar products. I will simply provide feedback on my personal experience with this product from several different points of view.

Aesthetics

I truly love the way the Kindle 2 looks. It has a very sleek profile and gentle contours that are reminiscent of the iPhone. In fact, the Kindle 2 is 25% slimmer than the iPhone. It has a solid white front with a nice, silver, metal case that covers 80% of the back. The navigation buttons are integrated into the sides of the case seamlessly and don't alter it's shape or feel but are prevalent enough to find by touch alone.

The keyboard is well spaced and big enough for easy operation by even larger than average fingers. The power switch and headphone jack are located on the top of the case while the volume buttons are located on the right side near the top.

The screen is approximately 1 1/2 inches taller and 1 1/2 inches wider than an iPhone's screen (yes I have an iPhone so that is why I am referencing it again). I'll discuss more about it's look a bit later.

Overall the Kindle 2 does what I think is the most important thing aesthetically and that is it doesn't get in the way. Meaning you won't be frustrated with layout or look or feel and you will focus on operation and use.

Aesthetic Rating: A

Use

Physical Operation

Power Button - This is my least favorite button which was scary since its the first thing I touched when I got it. The problem with the button is that it is NOT a button. It is a slider thingy (the technical term I believe) that always stays in the same place and to operate it you pull it sideways and release.

The issue I have is three fold:

The slider is smooth and has a low profile and my big fat calloused fingers rarely catch it clean the first try. If I haven't clipped my nails in a while I will use one of them to ensure I get it but between typing on keyboards and playing the guitar my nails stay pretty short.
I can't tell how far is far enough. Obviously if I get a hold of it I make sure I slide it as far as I can but more often than not I catch it just enough to move it slightly before it slips and I am not sure if it was enough movement to activate it. This is compounded by #3 below.
It takes a full 2 seconds for the screen to give any indication that I have properly activated the slider. So every failed attempt costs me at least 3 seconds as I stare at it waiting and then 2 more seconds to reach back and re-try and then at least 2 more seconds before it actually comes on. So best case is 2 seconds, worst case is 7 - 8 seconds from first attempt to activation (assuming of course you don't miss it again).

Navigation Buttons - I am fairly happy with these buttons. At first I was a bit frustrated simply because my natural instinct was to press on the outside of the button (closest to the edge of the device) to activate them. I quickly learned however that the activation point was to the inside. In the end this is not a terrible thing and I am giving Amazon the benefit of the doubt that they have done this to cut down on the number of accidental page flips or other unwanted navigations. Plus I am not such an old dog that I can't learn this new trick (at least new to me).

The buttons overall have a nice touch. There is a clear "click" (not electronic just mechanical) when you have activated it so you know you have succeeded (unlike that darn power slider thingy). It takes a little more pressure than you might think but I imagine that once again this is to cut down on accidental activation and it also may loosen up over time.

Location wise there are two buttons on the left side (Prev Page and Next Page from top to bottom). The right side contains 2 groups of 2 buttons (Home and Next Page in the top group and Menu and Back in the bottom group).

There is also a small orbital button that sits in between the Menu and Back buttons. This is used to move the cursor or navigate up, down, right and left through menus etc. In addition to the directional movements it can also be depressed to activate the current menu selection. Its location is convenient but its operation is somewhat clumsy. Once again having fat, calloused fingers does not help me here. The directional button has a low profile and a smooth top allowing it to NOT be accidentally moved but making it difficult to operate when necessary. Depressing the button is simple but pushing up, down, left or right takes deliberate effort. I am getting used to it so I am sure this will eventually be forgotten and I would certainly rather it take a little more effort to intentionally activate than easy to accidentally activate so I will give Amazon credit for that.

Keyboard - The keyboard is more than adequate for this device since I do not see myself utilizing it too much. The buttons are small but have a convex shape for a nice feel and are spaced out enough for even my big fingers. The layout is standard QWERTY but the keys themselves are arranged in a grid as opposed to being offset. The Delete, Return/Enter, Forward Slash and Period buttons fill in the bottom right corner of the grid while the space bar is flanked by the Shift, ALT, Aa (Font Size) and SYM buttons.

The keys make nice, clear "click"s when depressed that you can feel on you finger tips so you can type with relative ease and speed.

Headphone Jack and Volume Buttons - I have yet to utilize these and I imagine that unless I put some MP3s on for background music I probably never will. The only other reason would be podcasts or the Text-to-Speech feature but podcasts would most likely be on my iPhone and the Text-to-Speech feature is not worth listening to (more on this later).

Physical Operation Rating: B (just for that darn power thingy)

Features and Functions

Screen - Perhaps the most talked about feature of the Kindle is the screen and more specifically its e-paper display. I'll avoid the technical talk here since that is well documented and simply focus on my experience. I had heard much about this and even seen a few original Kindles but had never actually sat down and read from one. My first reaction was "Wow". I mean we're not talking end world hunger here but I have yet to get that menacing headache that crops up right behind my eyes when I've been staring at my iPhone or laptop screen (like right now actually). Much like the aesthetics, the best thing I can say here is that after initial evaluation you will forget about it entirely which is exactly what you want.

Below is a side by side picture of the Kindle 2 and a standard paperback.

As you can see, other than then "paper" color, there is very little difference.

Menus & Navigation - This is an area where there will hopefully be improvement in the future. There are two issues that I have. First is the relatively slow reaction time. There is a noted delay when you press the Home or Menu buttons and a less obvious but definitely existent delay when moving from item to item. Second is really just the fact that there is no free floating pointer or touch screen. Experience wise it is much like using the old Lynx browser where you must go up or down until you get to your selection. So if your selection is at the bottom, then you have a ways to go. Also, for the Home screen, if you want to change the sort or filter you must go all the way to the top before you can go right or left. Again, this is more a result of the interface than Amazon simply doing it poorly. So if there is any criticism it is in the choice of interface.

I'll take comfort in knowing that I will be using this as a reading device only and not a PDA or other hand held web device so these deficiencies won't be as frustrating. Of course you can easily see how this device COULD become such a device with some improvements.

Page Turns - The first question I get from Kindle 1 owners is "Are the page turns any faster?" Well I can't say they are faster or not but I can say that they are fast enough for me. After a bit of practice I quickly got my cadence down on when to hit the Next Page button. For me it is about 4 words from the end of the page since that is about the length of text I am reading at once. When I am on a roll the page turn never even enters my mind which again is the best compliment I can give it.

Looking at it purely from a speed observation (e.g. simply clicking the button when not reading and timing it), the Next Page displays in about .9 - 1 second while the Prev Page takes about 1.1 - 1.3 seconds. There is a flash on the screen as the text is swapped which can be a little annoying but like most things you get used to and then forget about it.

Check out this short demo:

Browser / Kindle Store - The Kindle 2 can be used not only to shop in the Kindle store but as a web browser as well. The browsing capabilities are very limited and again the navigation is very Lynx-esque. In fact think of Lynx with black and white pictures. In Amazon's defense, they say up front that text based web-sites are the best to use and of course the browser is "Experimental". I have found that mobile based sites are where you should hang out if at all. The Kindle store is optimized obviously for this browser so that experience is better but you must still navigate up and down to highlight the link you want and it is not always obvious where you are on the page.

Also, since there is no scroll bar, each web site is paginated which can get confusing. Rather than scrolling down to the next part of the story or to look at additional links or headlines, you must use the Next Page button which does essential that, it jumps to what it has determined is the next page. Needless to say that after a bit of playing around, I quickly found it to be distracting and slow and a waste of my time. I can only see me browsing the Internet if I had to (e.g. my iPhone, laptop and nearest Internet cafe were all some how inaccessible).

One note however is Amazon's regular website. This site is already well optimized for mobile devices and not surprisingly it plays pretty well with the Kindle. Again, you will typically use the Kindle Store if you are looking at Amazon, but if you were interested in simply browsing Amazon proper you could.

Dictionary - The dictionary is a very nice feature. While I don't see myself using it a ton, its nice to know that when I inevitably come across some word I don't understand, I can quickly educate myself. Its also nice that at any time I can move the cursor in front of any word and get a relatively quick response. There is no need to jump out of the text to another interface and type the word in. This makes it all the more likely that I will utilize it.

Text-to-Speech - What can I say about this other than the Audio Book narrators' jobs are safe. The speech is extremely robotic which is basically what it is since it is interpreting the text as it goes. It mispronounces even simple words ("lived" is pronounced "l-eye-ved") and often blows through punctuation marks thus making the sentences confusing and the story emotionless. If you are following along looking at the text it is fine since you can interpret the punctuation and mispronounced text. Of course if you are following along looking at the text you might as well just read it.

One interesting note is when I first tested this function, the first sentence contained the word "Facebook". To us humans that is a very common word but the Kindle 2 pronounced it "Fa-say-book". I knew then it was going to suck.

Miscellaneous

The Kindle 2 offers the ability to play MP3s while reading or I suppose just for fun like any MP3 player. To do this you must manually copy MP3 files onto the Kindle while plugged into your computer. Playback is fairly easy using the "ALT" key + Spacebar for Play/Pause and "ALT" + F to skip to the next song. The music will play through the built in speakers or through headphones. I was disappointed to find out that my iPhone headphones (the factory ones at least) will not work. More precisely, they function, but the extra length of the plug causes the contacts to misalign and you will only have mono sound. You can fiddle with it and find the right spot for stereo but it won't be secure. Big bummer since I might want to actually put some REAL audio books on there. I will now have to carry an extra set of headphones (or find an adapter) if I want to do that.

Another feature that I was excited about was the magazine and newspaper subscriptions. I enjoy reading Newsweek for example but only occasionally pick one up since I don't want the waste associated with a weekly magazine delivery. I quickly found though that a big part of the enjoyment of the magazine was in the form factor itself. The shape, the size, the feel of the paper, the color photos etc all contributed to the experience. As a result I have found my first two issues of Newsweek less than satisfying. I will continue to fight through it though since ultimately it is the content I am interested in and I will simply have to get use to this "new" method of information delivery.

There is also the ability to copy personal files such as Word documents and PDF files to the Kindle 2. It won't support these file types explicitly but Amazon offers a free service to convert them to the supported type. The officially supported file types for conversion are:

Microsoft Word (.DOC)
PDF
Structured HTML (.HTML, .HTM)
JPEG (.JPEG, .JPG)
GIF (.GIF)
PNG (.PNG)
BMP (.BMP)
Compressed ZIP (.ZIP) - ZIP is opened and all supported files are converted.

This makes it very nice if you have some documents you would like to read on a trip and don't want to print them out or open your laptop. You can either have the files converted and manually copy them or you can have them emailed to your device for a fee of $.10 per document. The conversion process is very simple and involves sending an email to your Kindle 2's email address (xxx@kindle.com) with the document attached. The document will then be automatically sent to your Kindle 2. To avoid the fee and manually copy the document, you send the email to a slightly different address (xxx@free.kindle.com) and a response will come back to email address you sent it from with a link to the document you can download and then copy.

There are some additional features such as Notes, Bookmarks and Search all of which I will use in a limited fashion I suppose. Bookmarks will be nice when reading a technical book so I can go back and reference various sections and I'm sure students or book club members might utilize them to recall certain passages and important sections. I mainly see myself opening a book and reading it and that is basically what I have done thus far.

Features and Functions Rating: A-

Summary

Overall I have been very pleased. I was not expecting an end all be all device. Rather I was expecting a device that allowed me to read books without carrying them around. I also love being able to read multiple titles at once without reaching for another book. In fact I have been going back and forth between a technical book, a novel and a history of the American Presidents since I got it, something I would never have done had I been forced to carry them all around with me.

One interesting thing I have noticed is the potential for this device to cost me a LOT of money. It is almost too easy now to get a book I want. No trip to the book store, no waiting for delivery and in fact no waiting at all.

It would be nice if I could get Kindle versions of books I have already bought on Amazon for free or at least at a discount. I am also a little disappointed at the cost of some of the books such as the technical books I like to read (well "like" is a bit strong, let's just go with "read"). I typically was spending $25-$45 on some of these books and was hoping that I could get them at half price or less on the Kindle, however many of them are only $10-$15 less which is disappointing. I would like to get many of the technical books I already own on the Kindle but I am not going to pay almost full price just to get a soft copy. I would rather scan each page and copy them to my Kindle than do that.

Well that is all. I'm sure I will find some features that I did not even know about later and may find that I love something I hated and hate something I loved but all in all I am happy with my purchase and am enjoying the experience.

Overall Rating: A

RSS (No not that one)

2009-02-19T10:19:00.000-08:00

Right Sized Security

What does this mean?

Security is a big FUD word we like to throw around. You need it, you want it and God only knows what will happen if you don't have it. Until of course you have to pay for it and then you might decide to take your chances.

That is what I typically see when discussing Web Services security. At first mention everyone nods their head as if to say "Of course we need security." That is usually about as close as they get to actually having it.

The issue I see is the lack of understanding or at least acknowledgment of what security means and specifically what different types of security there are and which ones are needed. Security is an umbrella term that covers several different concepts:

Authentication
Authorization
Confidentiality
Integrity
Non-Repudiation

Each one of these is a topic in of itself and you can readily find entire books, articles and products targeted for each one. So simply saying "We gotta get us some security" is really the beginning of a much larger discussion.

The idea behind Right Sized Security is to apply only those aspects of security that you need or want and to do so in a way that does not completely overwhelm your environment. Let me give you an example:

Suppose you are going to offer a simple identity service that will retrieves names, titles, managers etc from your corporate LDAP. The service will only be available within the company's local network and the data that will be passing back and forth is available to everyone who wants to see it. However, you would like to know who uses the service so you can track your dependencies and analyze the value added by this service.
No data is being updated so there is no need to worry about non-repudiation
The data is available to everyone so there is no need to provide confidentiality
The data is informational only so the threat of alteration in transit is low and thus the need for integrity is very low
There are not different access levels for the data so authorization is not needed
Everyone is allowed to use the service but you want to know who and how many times each person or application is using it so some sort of access control or authentication is needed
From this analysis, it is easy to see that a solution involving encryption or digital signature or some other advanced technology is far too complicated.

You need to be willing to utilize several different security models based on need and not get sucked into a one-size-fits-all approach. Most importantly, take the time to add a security analysis to your process and address each security concern individually. Combine this with a matrix of best practices and apply the "right sized" security model. This will make adoption easier and may actually result in you having some of that much desired security.

Gartner AADI 08 Orlando Wrap Up

2008-06-11T13:22:00.000-07:00

Well the conference is winding down and I'm taking an SOA breather to
reflect and exhale. Well I'm actually watching EURO 08 but I am
reflecting.

I have to say that all in all I enjoyed the conference. I especially
enjoyed seeing and meeting the other members of our team. We stay
pretty busy and unless we're together on a job we don't see each other
often.

I was pleased to see that many of the concepts, patterns and processes
presented were not new to me and in fact were things that myself and
the rest of the team already do and apply everyday. Of course there
are always things to learn or new perspectives to discover. I met some
nice folks and had fun in the unsanctioned events as well ;)

Gartner AADI 2008 - Day 3

2008-06-11T10:03:00.000-07:00

Gartner AADI - Day 2

2008-06-10T06:54:00.000-07:00

Best Practices in Enterprisewide SOA Initiatives presented by Massimo Pezzini

Gartner AADI - The SOA Journey presented by David Lindley

2008-06-09T12:50:00.000-07:00

David Lindley from Blue Cross, Blue Shield of Florida presented their SOA journey. One of the many nice things they have done is to create some artifacts that outline their road map and vision. What's even nicer is that they come back to these documents to evaluate their direction and decisions. They have created service request documents, service contracts, documented their service life cycle and put architectural reviews in place for new services requests as well as change requests. The have an intermediary, a registry, a testing solution and a monitoring solution. They defined and published their standards, created development guides for services and even created an EA web portal for all of this information to be disseminated and shared.

This is of course merely the short list of all the work that David and his team have done. They have done a fantastic job of envisioning where they wanted to go and creating the necessary checkpoints and artifacts to get there.

I had the privilege of working with David early last year and while he and his team deserve all the credit for their accomplishments, I'm proud to have been a small part of their efforts. David and the other members of his team are a great example of what can be accomplished when a group of talented and passionate architects get behind SOA.

The other key success criteria required to achieve lasting benefits is enterprise support. It remains to be seen if this criteria is met at Blue Cross. For their sake, I hope they realize what a great team they have and what great work they have done.

Gartner AADI - Service Oriented Development presented by Michael Blechar

2008-06-09T12:13:00.000-07:00

Michael described an interest point concerning BPM. When a business unit starts documenting and defining their business process, not only do they start to get value through visibility and repeatability but they quickly start to see the value of SOA. This is due to the fact that once the processes are documented, people will want to fine tune and alter them to accommodate changing requirements or to make them more efficient. They will quickly see that without separating the individual units of work or activities they are not able to achieve this flexibility. Additionally, other units will see the processes and what to utilize them in whole or partially. Again, without the separation and granularity this is not possible.

The bottom line here is that BPM can sell SOA. Thus by supporting and promoting BPM, you will also be exposing the need for SOA.

Gartner AADI – Moving towards Advanced SOA presented by Yefim Natis

2008-06-09T12:10:00.000-07:00

An interesting concept is the idea of Software Oriented SOA and Business Oriented SOA. The difference being that one is technology focused and one is not. While it’s never accurate to break things down to only 2 sides, there is some value is evaluating your SOA initiative against this dichotomy.

This difference was noted as a “Thing to Avoid” in Yefim’s morning session here at the AADI conference. A Software Oriented SOA is one which is driven largely by the developers and “techies” as Yefim called them. There is little if any business alignment and services are viewed as software deliverables. A Business Oriented SOA on the other hand blends the technology with the business and views services as business enablers.

The results of these two approaches can and will be drastically different. Without a business focus, most SOA branded activities will ultimately lead to further disconnect and added complexity.

Obviously Yefim’s presentation covered much more than this but this one point resonated with me as I have personally seen instances of both types of SOA initiatives and I think you can guess which ones have been more successful.

SOA Challenges: Silo Service Development

2008-02-11T19:00:00.000-08:00

One of the more common things I am seeing these days is the development of services in an application or siloed context. The popularity of and propaganda about web services has made this type of development very popular.

Rather than creating a .NET or Java API as they would have in the past, teams now simply create a Web Service API. Unfortunately, since these services are not being created with a broader picture in mind, there is no focus put on schema development or reuse, namespace management, consistency or versioning, WS-I compliance, top-down design or interoperability.

Essentially what these teams are doing is adding more complexity to their system then they would have had if they created a typical interface. Furthermore they are adding latency and reducing the performance of their system while not getting any of the other added benefits of a more managed service oriented approach.

Additionally, because these projects contain all the traditional tiers (Data, Business Logic and Presentation) they are also responsible for consuming the very web service they are creating. Simultaneous development of a service and its consumer is very difficult without a structured and planned approach. There is no single correct way but typically it involves a defined, solidified interface and a dummy implementation. This allows the consumer development to proceed unimpeded by the service development. The service team can then “release” operations individually and do integration testing on a smaller scale allowing the system to gradually take shape rather than going for the "big bang" integration approach.

Many companies are on this path. Those that have no centralized or organized SOA effort are inadequately prepared to change this behavior. Those that do (yes, even companies who have great SOA stories fall victim to this) need to ensure that NO web service gets created without the SOA team's knowledge and influence. If nothing else, the SOA team needs to be aware of the project and either help the project team align their services with the broader vision or prepare (and plan) for a refactoring effort later on.

SOA Challenges: Schema Management

2008-01-21T12:25:00.000-08:00

Everywhere I go I see this challenge. How can you create a network of interactive, useful, business oriented services if they do not speak the same language?

I'm not talking about the format in which data is transferred (e.g SOAP or POX or JSON). I talking about the business specific semantics used to represent the data. Just because two people speak English does not mean they can communicate. They must have a vocabulary they both understand. Have you ever listened to a NASCAR post race interview? I'm pretty sure that's English but I have no idea what they are talking about.

The same is true when developing services.

Web Services are officially the flavor of the month. Every project now at the very least involves a web service API and many utilize web services as their only business tier API. While this is a topic in of itself, as it relates to the topic at hand, this is root of the problem.

A recent post by Jeff Schneider points out this issue and leaves little hope for the traction it is getting. The desire and push to develop services has lead almost everyone to do their leaping before their looking. It is these same people who will eventually proclaim SOA just another passing fancy even though they did little to make it a success.

Of course in order to do this properly, an enterprise needs to provide its teams with the appropriate tools and resources in which it can be accomplished.

To name a few:

A centralized object repository
Tools for navigating and extending existing objects (both internally and externally managed schemas)
A versioning solution
An environment for hosting and referencing all internal schemas (e.g. http://schemas.mycompany.com)
Governance around the use and proliferation of namespaces and objects (I'm talking to you EAs)

I am currently evaluating a solution I hope will offer all of these things so I will let you know what I find. Stay tuned...

The Sweet Comfort of the Maturity Model

2007-08-07T18:58:00.000-07:00

Not long ago I was talking with a colleague about various SOA implementations we had seen. On one in particular I commented that it was not a SOA but rather what I like to humorously call JBODMWS. That of course stands for "Just a Bunch of Discoverable, Managed Web Services". This is definitely better than what a lot of companies have, but I stressed that simply registering a bunch of web services from different departments and different lines of business does not a SOA make. Even managing the services centrally, while a significant step in the right direction does not qualify as SOA. In fact, what it qualifies for is exactly what I called it, JBODMWS.

My colleague maintained that it was indeed a SOA. This of course set me off on my lecture circuit on how SOA was not about creating a bunch of web services and registering and managing them. Its about composition and granularity and categorization and flexibility and, you know, all that other stuff. Once my colleague understood my argument he made the comment that to this day perplexes me. He said, "OK, I see. But it is still a SOA, its just a SOA maturity level 0."

What do you say that? I can't argue with it. Its not UNtrue. But it certainly isn't necessarily accurate. Needless to say our conversation ended then and there and I have been thinking about it ever since.

What is this monster we've created called the Maturity Model? Sure its useful and when used in the correct context it can be a very important measuring stick. But is that how it is being used? Are people comparing themselves against the model, determining where they stand and then making plans and preparations on how to get to the next level?

I'm afraid to say I don't think so. I think people are evaluating where they stand, finding they are at level 0 or level 1 and then forgetting about it. Did they do anything to get to level 1? Probably not. Maybe next time they evaluate themselves (or have some else do it) they will find they are at level 2. Great! But how did you get there. Did you mean to? What level will you be at the next time you evaluate yourself? Will you even do it again?

I think in reality the maturity model is being used as a blankey. You know the thing Linus had in the Peanuts. It seems to make people feel good about where they are. Consider the following:

Which makes you feel better?

- Your fat

OR

- Your skinny maturity level 0

To be fair, the blame needs to be spread just a bit. It is not just IT departments that are snuggling in the warmth of the maturity model. It is the consultants as well. Do you have the balls to tell someone they are not where they think they are? Or will you just tell them they are maturity level 1 and make them feel better.

Don't get me wrong, I am not saying to hell with maturity models. I'm just saying, don't let it be a passive artifact you warm up to in order to explain your current state. Let it be an active artifact that you are consistently measuring yourself against. Your plans should involve a strategy for achieving the next level. Only then will you be using the maturity model for what it was meant for.

Until next time,
This is Jason Henley, International Heartthrob... Maturity Level 0.

SOA, I could just K.I.S.S you! - Part 6

2007-08-03T10:16:00.001-07:00

Welcome back. If you missed the first five parts of this series, please follow the links below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education

Step 3 - Organizational Governance

Step 4 – Evaluate Your Infrastructure

Step 5 - Pilot Project

Step 6 - Wrap up
Wrap up.... Wrap up!! How can I just wrap it up now when there is so much left to do?

Well its simple (the theme remember). Much of what is left to do simply involves sticking to it. Learning at each step. Actually allocating some time to analyze services for compliance and reuse opportunity etc.

Now I realize that I've left out some huge pieces. Namely Business Process Modeling, Master Data Management, Service Design, Service Management, Orchestration, Security, Service Life Cycle Management, Service Versioning... I think I could go on for a while but I'll stop there.

These are all very important topics and things that you need to look at and address. The point I want to make is that you do not have to paralyze yourself by taking all of this on at one time.

I hate to say it because it feels like a give up but Rome was not built in a day, and assuming your SOA actually gets built, it will be no different.

At the very core of SOA, in my humble opinion, are very simple concepts not complicated ones, and while the solutions themselves are not always simple, keeping those simple concepts and goals in mind will help you see the solutions that are right for YOU!

SOA, I could just K.I.S.S you! - Part 5

2007-08-03T09:48:00.001-07:00

Welcome back. If you missed the first four parts of this series, please follow the links below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education

Step 3 - Organizational Governance

Step 4 – Evaluate Your Infrastructure

Step 5 - Pilot Project

What more can one say about pilot projects. If you do a search right now for SOA Pilot Projects, you will find somewhere in the vicinity of 300 results, one of which is an article co-authored by MomentumSI's own Alex Rosen.

So to save time (mine) I will simply concede that there is not much more information I can add on this topic. I will therefore leave it at this:

1) DO A PILOT PROJECT!!!

2) Learn from said pilot project

3) Roll those lessons into your overall plan (if you need more infrastructure, now you at least have some data)

4) Finally, tackle another project only this time, do it better.

I'll close this wonderfully short entry by passing along some great advice I once read:

Lather, Rinse, Repeat... Ah the simplicity....
____________________
Next Step - Wrap up

SOA, I could just K.I.S.S you! - Part 4

2007-06-25T14:27:00.000-07:00

Welcome back. If you missed the first three parts of this series, please follow the links below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education

Step 3 - Organizational Governance

Step 4 – Evaluate Your Infrastructure
Hopefully by now you will have found an SOA champion, identified resources for the COE, defined some initial processes and created a general messaging profile. Now it is time to start thinking about your infrastructure.

STOP!

Before you go out and start evaluating various SOA infrastructure products, you need to consider the following:

You do not need to build out your entire SOA infrastructure at once.
You will not know what you need or want until you actually go through some pilots.
You will be easily swayed by vendors unless you understand the implications of various features or the lack there of.

Typically the first piece of infrastructure that people go after is the registry. We’ve read and heard about for years how the first thing you need in your SOA is a registry. This approach however has two practical problems. First, most registry vendors no longer offer JUST a registry but rather an entire automated design-time governance solution. This is great on paper, but shouldn’t you actually establish some governance processes before you start automating them? If you don’t, your governance processes will essentially become whatever the product you choose supports. Second, why do you need a registry for services when you don’t even have any services? This is equivalent to Alexander Graham Bell selling a phone book before anybody had phones.

This may sound slightly against the grain, but I don’t believe that a registry is the first product you should add to your SOA infrastructure. There is nothing wrong with starting out with some manual governance as you walk through the initial phases of your SOA initiative. Your first consumers will most likely not be using UDDI to discover your services, negotiate contracts and bind to your endpoints and you certainly will not be evolving so quickly that you need to deal with things like version management or dependency tracking. Everything can be taken care of with good old fashion communication, especially in the controlled environment that you will be working in initially. It just doesn’t make sense to start automating something you haven’t even done yet. If you do, you will be trying to learn how to automate and how to govern at the same time. Rather you should be focusing on learning about service types and layers, how to identify reuse opportunities and how to model your domain along with how to govern at design-time.

Remember, the theme is “Keep it Simple”. Think about what you need right now and not what you THINK you MIGHT need or what vendors TELL you you’ll need. Think about the goals: interoperability, platform independence, reusability. This boils down to 2 things: XML and HTTP. Since you should have already thought about some other requirements (remember the messaging profile), you may have further refined this to include things like SOAP and WSDL (or maybe not, it all depends on your NEEDS). If security beyond SSL is required (for example encrypting portions of a message for persistent stores like auditing and logging or for end-to-end security through intermediaries), WS-Security enters the mix. What about reliability? Do you have business drivers that require guaranteed delivery of a message? If so, then WS-ReliableMessaging and maybe even JMS come into play. Given all of this, you should evaluate your current toolset and determine whether or not it can support your immediate requirements. If not, then that is where you need to start.

I can’t stress enough how important it is to take an “as needed” approach. If you go out and purchase management, monitoring and governance products before you have designed and deployed a single service, you will constantly be under the gun to utilize and show return on those investments (which will be significant) not to mention overwhelmed with a slew of new products that no one knows how to properly utilize. Add to that the fact that ROI is sometimes hard to quantify (often coming in shorter maintenance cycles, better accommodation of change requests and less headaches overall) and you may be so far behind the eight-ball that you have no chance of succeeding.

You must let the game come to you. As your knowledge and overall organizational maturity increases, so will your ability to strategically add pieces to your infrastructure that make sense and satisfy a need. The best way to start out down this path is to identify some of those needs. This means finding a pilot project. Once you identify a pilot project, you can use it to determine (or validate) what your requirements are and from that determine what if any products you need to acquire. Remember, this step is about evaluating what you have against what you quantifiably need. As such, building out your infrastructure doesn’t necessarily mean buying products. It might simply mean re-appropriating existing tools.

As mentioned above, a pilot project is a key piece to this step. As such, the activities described here will overlap with the next step which is of course the pilot project. Much like education, this step is one that will be ongoing throughout the life of your SOA for there will always be new requirements, new challenges and new solutions.
____________________

Next Up: Pilot Project

Thinking Inside the (Black) Box

2007-06-15T10:28:00.000-07:00

I will get back to my K.I.S.S. plan soon I promise. But first I wanted to put this out there.

When you order a book from Amazon, do you really care what happens between the time you click the Submit button and the moment the book arrives at your door?

Besides the confirmation and shipping notification emails you receive, your interaction with Amazon (for this transaction) ends once you hit that button.

What would you say if I told you that when you click that Submit button, a piece of paper prints out and a buzzer goes off that signals a monkey to grab the paper and run it across the room and put it through a slot in the wall? Would you care?

What if I told you that on the other side of the wall were scores of high school track team members decked out in full running gear that took the piece of paper and sprinted out of the building, down the road and into the warehouse where they put the piece of paper through another slot in a wall? Would it bother you?

What if I told you that on the other side of that wall was a series or ordinary but organized white boards that neatly listed the exact quantity and location of each and every book in the warehouse and that someone quickly located the book you ordered and wrote it on the paper and slid it through another slot on the opposite side of the room? Would you lose any sleep?

What if I finally told you that someone on the other side of that wall picked up that piece of paper, jumped on a forklift, found your book, wrapped it up and dropped it in the mail? Would you ask for a refund?

Barring the mistreatment of animals (I can assure you the monkeys are well taken care of) or the existence of child labor (all the high schoolers are of age), your answer has to be a resounding "No! I don't care"

The bigger question is: Why don't you care?

You don't care because HOW it happens is not important. What's important is the fact that it happens and furthermore that it happens in the expected amount of time.

This is of course the easiest possible example to give, and while this is certainly NOT Amazon's order fulfilling process (at least I hope not), it is of no consequence because Amazon is operating as a black box. What does that mean? That means that we only care what goes in, our order, and what comes out, our book. What goes on behind closed doors is irrelevant to us.

This is neither a new concept nor a unique one. You probably encounter such a situation about 100 times a day. Where does your food come from? What about that coffee? Do you even know how your mail gets to you other than a person drives it (or walks it) to you? No you don't and ultimately, other than natural curiosity, you don't care.

So what then is the big deal? Well the big deal is not the big black box. The big deal is what is in the black box.

Many processes are written as a single black box. Input comes in, gears turn, lights blink, data is processed and output returns. While this is still of no consequence to the consumer, the owners of this process, the ones that do know what's in the box, are saddled with one giant machine. When that machine is working, life is good, but when that machine stops working or needs new parts or is due for an upgrade, the whole operation is affected. The only solution to avoid down time is to have two giant machines and take them down one at a time. Not exactly the end all, be all solution.

What then can be done? Well, for starters, let's explore this black box concept a bit more. What makes the black box so appealing is the independence that is achieved between the consumer of the process and the process itself. As long as the rules of interaction don't change, the consumer is unconcerned with the inner workings of the process. This independence provides enormous freedom to the consumer as well as to the provider since the process can be changed freely as long as the interaction contract is upheld. Even if the contract requires alteration as part of other process changes, the consumer need only be concerned with the changes that directly affect them, and not what's going on inside the box.

Well this sounds like a nice situation to be in. Freedom to make a change without notifying consumers (we're talking technical changes here only). Even our "two giant machines" approach works here since one can be brought down, changed and then brought back up followed by the second one. The consumers have not been impacted (with the obvious exception of performance), and the process has been upgraded.

But what if the upgrade only applies to a very small portion of the process and is a very minor change? Does the whole process really need to come down for such a minor change? Will the business owners understand why the entire system is affected by something that by all accounts is minor? And what of this minor change? Is it really as minor as it seems or are there other dependencies that have not been identified? The process is one giant machine. The designs for the machine are still available, but have they been updated with every minor change that has happened since it was first built? How many minor changes happened before it was even completed?

Perhaps this change, the one that seems so minor, is not so minor after all. Perhaps it is major. Perhaps it is beyond major. Perhaps a thorough audit of the process is necessary to evaluate the impact of the change before the change is even planned. How long will that take? What's the ROI of such an allocation of resources? And what about the new features that were planned for the process? Will they now have to wait until someone figures out how to make this "minor" change? Suddenly that giant machine, excuse me, I mean both of those giant machines, have lost some luster. Suddenly things have come to a grinding halt. And why? Because you wanted to make a minor change. Try explaining that to your boss.

Ok, so what then? Well the answer lies within, so for once, I will tell you to think inside the box. The same freedom gained by the first black box's isolation can be expanded. Think of a Russian Stacking Doll. From the outside it looks like a doll. But within each doll is another doll. While this is a fairly rudimentary example, the same can be done with black boxes.

Let's look at the fictional Amazon process closer. We have already established that when you enter your order, you don't care where it goes or how it gets there. Your order has thus entered a black box. When the order prints out and the buzzer goes off, the monkey has no idea where the order came from nor does he care (assuming he would even understand but these are Amazon monkeys remember). You may have submitted it from home on your laptop or perhaps on a train with your wireless. Heck, for all the monkey knows, you could be on the other side of the wall tapping out your order in Morse code. So while you don't care how your order gets fulfilled, nor does the process care where your order came from or where it is going (of course it must know where it is going so it can get it to you and who it is going to so it can bill you, but these are simply points of data not permanent relationships).

The interesting thing here is what happens next. The monkey takes the order and slips it through a slot in the wall. At this point, the monkey is done with his job and can go get a treat. So not only did he not care where the order came from, he didn't care where it was going other than through the hole in the wall. So in essence, the tasks of printing the order and delivering it is its own process and has itself been created in a black box. This is important but let’s keep going.

Now the order comes to the high school track team members. Once again, the students have no idea that a monkey has just hand delivered this order and once again they don't care. Their job is to take the order and run to the warehouse and slip it through the wall. That's it. Job done. Get some water and walk it off. Again, black box.

The order is now in a room with hundreds of white boards all delicately spaced to avoid the accidental butt erasure. Those in the room have no idea and no time to worry about how the order got there. They need to pick it up, find the book, write down its location and get it to the other side of the room as fast as possible. Black box.

Once there, the warehouse worker has no idea that this order has passed through the hands of a monkey, a high schooler, and a slightly loopy (from all the dry erase markers) clerk. But once again, he doesn't care. His job is clear. Get the book from the location on the order, package it and mail it to the address on the order. You guessed it, black box.

We could keep going with the mailman picking up the package or the mail processor routing it correctly all the way to your friendly mailman who delivers it to your door, each one not knowing or caring exactly how the package got into their hands. Black boxes, each and every one.

So what? What have we shown? Instead of one black box, we showed several. Big deal right? Right! It is a big deal because the very freedom that once existed only between the consumer and the process now exists within the process itself! Each black box has very specific (albeit simple) interactions, namely a slot in the wall. The input? A piece of paper. The output? For all but the final step, a piece of paper. What if the monkeys become belligerent? What if they start passing their poo through the slot instead of the order (I've seen code that actually does that)? Do you shut down the whole process until you can find more monkeys? No. Simply find some well trained dogs, put them in another room, and start routing the orders to them instead. The high schoolers still get the orders and have no idea that anything has changed (although the saliva might give them a clue, but they're high schoolers so their use to that right?).
What about when all the high schoolers are taking the SATs? Do you need to shut things down? No. Simply go grab some kindergarteners (with parent approval) and buy a bunch of candy. Trust me, they'll go for hours and hours and hours and...

Don't look now, but if you haven't already noticed, no where in their little process here has Amazon actually billed you for your order. Oops! The solution? Yep, you guessed it, buy a bunch of parrots and put little colored visors on them. Have the orders from the monkeys (or the dogs if the monkeys have already started throwing poo) go to the parrots' room. They can process the billing and then pass the order through their own slot to the high schoolers and off they'll go.

The monkeys and dogs have no idea any thing has changed and neither do the high schoolers (although they are starting to ask questions about the feathers now stuck to the saliva). So just like that, the process has been upgraded and no other portion of the process was impacted.

One more. Amazon has decided that it can save time and money on white boards if it uses them to track only inventory and a sophisticated rolodex system to track the locations of the books in the warehouse. So a new room has been created to house the rolodexes. The clerks in the white board room now need to verify the availability of the book and then pass the order to the rolodex room to get the location. The rolodex operators write down the location of the book and returns it to the white board room where the inventories are updated, and the orders are passed on to the warehouse floor.

High schoolers: unaffected. They still deliver the orders the same way. Warehouse workers: unaffected, orders are still delivered the same way with the same information. The only ones affected are the white board clerks who must now perform three tasks: Check the inventory, pass the order to the locator room and then update the inventory.

The point of all of this is simple. Why create one giant process when you can create several independent processes that work together to form that giant process. In fact, many of these processes are so simple that you can hardly call them processes. Instead, let’s call them services.

I know, I could have just said that from the beginning right? But that is exactly what we've created here. Services. Each one focused on a specific task and each one using a mix of processing and other services to accomplish their work.

I know what you are thinking. "Amazon, monkeys, dogs, parrots, high schoolers; this is all cute but the real world is not that simple."

Ah, but isn't it?

I'll grant you that your black boxes will not be so easy (or fun) to design and build. It takes time and perspective to see all the pieces and to decide which of those pieces belong together and which belong apart. But don't let time and effort be the deterrents that prevent you from accomplishing the end goal.

But what exactly is the end goal? That can best be answered by returning to the single black box we described earlier. Remember that minor change that turned out to be not so minor? How much money would ultimately be spent trying to make that small change? How many person hours would be wasted? How much revenue lost because you had to delay new features that new sales were depending on? It all adds up and it all adds up quickly. It won’t be long before your competitors either catch you or surpass you in features and sales. Soon you will be the ones playing catch up and all because it takes an enormous amount of time, effort and money to make simple changes to your process.

But, perhaps your process is not like this at all. Perhaps your process is nice and clean and can be changed easily and was designed to be flexible. If this is the case then I commend you. But what about other processes in your organization? Does your process rely on any of them? Are they designed as flexibly as yours? If not, your process is at the mercy of those not so flexible processes. Maybe your process is self contained and does not have dependencies. Great, but do any other processes do similar tasks? How much time and money could be saved if those similar tasks were combined and shared?

I am not going to tell you that this is an easy thing to do. There is no magic bullet and no product that will do it for you. It takes time and it will take money to create processes and systems that are capable realizing this vision. But what I will tell you is that time and money spent now will have huge returns down the road, and if you truly commit to the plan and see it through, then those returns will not be as far down the road as you think.

SOA, I could just K.I.S.S you! - Part 3

2007-06-06T08:00:00.000-07:00

Welcome back. If you missed the first two parts of this series, please follow the links below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education

Step 3 - Organizational Governance
This is where the rubber starts to hit the road. But again, realize that you still are not ready to hit the highway yet. This step involves getting your resources, processes and policies defined. In addition, you also need to begin thinking about funding strategies.

Resources
This is the time you need to identify who will be part of your SOA Center of Excellence (COE). This group will bear the burden of SOA for the initial phases and be responsible for defining the processes and policies and driving the effort forward. The idea here is that a small group can learn and evolve much faster than a large group. The goal should be that the members of the COE will eventually disperse into the enterprise and share their knowledge. As such, this group should be made of a diverse group of people from different areas of the organization.

Processes and Policies
It is important to remember here that you need not solve all the problems on the first pass. SOA is an evolutionary process and as such, you should focus on getting some best guess processes and policies in place. For processes, focus on strategies for identifying, requesting and evaluating services. For policies, focus on things like security, message exchange patterns and messaging profiles (e.g. WS-I Basic Profile and Basic Security Profile). Identify who your consumers might be. This is still early, but taking the time to think about this will help you identify the types of service interaction you need to consider moving forward as well as some educational topics you might want to consider (do you know what REST really means?).

Funding Strategies
This is never an easy task and there is no one way to go about it. The proper funding strategy for your organization is dependent on a host of parameters. Some of those parameters include: existing project funding model, existing infrastructure funding model (if any), willingness of project managers or budget owners to contribute to the effort, C-level support or mandate etc. In the end, you will find that this will be the biggest obstacle to your SOA effort. Without budgetary backing, all SOA activity will remain on the drawing board. Below are few possible paths to take, but again, these are nothing more than high level suggestions that should be adjusted to your environment:

Establish a Shared Services Budget - This approach represents a very communal strategy by setting up an environment that is conducive to success. The shared services budget is aimed at accomplishing two things. First, by setting aside money for build out of the shared infrastructure it allows the COE to lay some necessary groundwork and to continue to improve or maintain the common infrastructure. Second, by providing a community chest of sorts, it serves as a buffer to project teams who want to include either the utilization or creation of shared services in their project plans knowing that they will either spend less money (by utilizing) or have the costs (of creating reusable services) offset. A very important part of this approach is reconciling a project team's costs against contributions to or utilizations of the shared services infrastructure. Without doing this in a very visible and communicated manner, project teams may be reluctant to interact with the shared services for fear of coming in to far under budget and having subsequent budgets reduced as a result. This may sound counter-intuitive (that project teams don’t want to save too much money), but it is a reality in many organizations. Inevitably the goal IS to reduce the budgets across the board but it must be done in such a way that project teams do not feel as though they are being targeted for downsizing.
Create Incentive Programs - This approach represents the carrot. Offering incentives to project teams to create or use shared services will motivate people at a very real level. It’s very difficult to convince employees that operational efficiencies and budgetary improvements will translate into monetary savings that will trickle down to them. Instead, offer them short term incentives for suggesting, creating, driving, promoting and utilizing shared services. These incentives can be both team oriented (a long weekend, a nice dinner, recognition on corporate internal network) and personal (commendations, bonuses, raises, promotions). There still needs to be some general funding for the creation of the common infrastructure as well as periodic maintenance, but this money will be exclusively used for those purposes and not allocated to teams as they contribute. A key part of this approach is to recognize and not penalize project teams for going over budget if the extra money was spent contributing to the shared services. Obviously these efforts need to be coordinated and planned, but project teams need to be encouraged to think about the bigger picture and know that they will not be penalized for their efforts.
Create SOA Mandates – This approach represents the stick. Creating mandates to contribute to or utilize the shared service infrastructure will force project teams to make reuse a part of their process. Optional tasks are often the first ones to go when the schedule and/or budget start to become a factor. By creating, communicating and enforcing SOA policies and procedures for the project teams, they will have no choice but to alter their process to incorporate them. Obviously a very important step in this approach is to create clear, strategic and aggressive policies regarding the incorporation of the shared service infrastructure. The reason the policies need to be aggressive is to account for the natural learning curve of the organization as a whole. The organization will inevitable fall short of what ever policies are put forth initially, but by making the policies aggressive, you ensure at least a certain level of success and at the same time the organization will learn what is expected. The key here will be to slowly ramp up the enforcement of the policies or more specifically, to slowly increase the penalties for non-compliance. Initially, the enforcement should take on a mentor’s role where teams are warned rather than punished and shown how to succeed rather than penalized. As time goes by and the maturity level (or expected maturity level) increases, enforcement will become more penal.

Continuing Activities
Don’t forget that this entire process is cumulative. This means that the support you got in the beginning needs to continue to be there and continue to be communicated. Monthly updates or a recurring newsletter from the SOA champion (with contributions from the COE) will keep the effort in the fore front and help ensure that this isn’t one of those initiatives that gets hype in beginning and then forgotten about (The company may be used to that unfortunately).

In addition to continued support, there must continue to be education. This will include both continued education for the COE, continued enlightenment of the SOA champion and the beginnings of education outside the COE for people such as key business owners, interested project leads or anyone else who comes calling. The key here is to provide interested and key parties with the information they want or need, but not to hijack them and force them into day long learning sessions. Eventually such sessions will be beneficial, but for now, focus your efforts on those who want to be a part of the effort and those who are essential for success. If you make the effort public enough and get consistent reinforcement, you may be surprised to find how many people come to you.
_________________________________

Next Up: Evaluate Your Infrastructure

SOA, I could just K.I.S.S you! - Part 2

2007-06-04T14:21:00.000-07:00

Welcome back. If you missed the first part of this series, please follow the link below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education
Now just because the name of this step is "Education" does not mean this is the only time that education will be taking place. In fact, it is safe to say that the entire process is about education as much as anything. But here in this step, education is the primary task.

****WARNING****
This is a typical place where things start to go wrong. Instead of taking the time to become educated on the various problems, possible solutions, vocabulary etc, many companies go right out and start implementing services or buying "Service Oriented" middle ware only to realize in time that they have no idea what they are doing. Of course then they will have invested time and money in some product or some group of services and stepping back away from money spent is a hard thing to do for any company. The natural tendency then becomes to push forward and make do with what you have. This results in more consulting fees, more product acquisition and more time spent going sideways or backwards. It won't be long before SOA is a four letter word and all hopes of achieving it are gone.

Before going down this road to despair, you need to start learning what SOA is, what problems it solves and what the challenges are regardless of whether you think you already know or not. You will undoubtedly find at least one thing that you weren't aware of or perhaps find that something you thought you knew was wrong. Any bit of knowledge gleaned from this is a success because you are progressing down the path.

One tidbit I'll offer is this: SOA is not a box of new ideas. In fact, you will find that SOA emphasizes many of the same concepts that have always been good ideas (Information Management, Governance, Business Process Management etc).

At each step, you will find that continued support from the top is important. Facilitate this by having regular updates with the SOA champion so they can see the progress you are making. Try to educate them as well as you educate yourself. Take care not to focus on the technical aspects to much when doing this however. Their main interest is how it affects the business. If you can continue to show how the business will be improved through your efforts, then you will continue to get support.
_________________________________

Next Up: Organizational Governance

SOA, I could just K.I.S.S you!

2007-06-04T14:15:00.000-07:00

No I'm not a weirdo with some software fetish. By K.I.S.S of course I mean the tried and true "Keep it Simple, Stupid" method. Now I am not saying that SOA is simple so let's get that out of the way right now. I've been doing this long enough to know that it is far from simple. In fact, I've been doing this long enough to know that it is actually quite complex. Of course like most things in the software architecture world, we over complicate it to the point where we either paralyze ourselves or paralyze the very people we are trying to help.

Show of hands:
How many of you have sat through an SOA lecture or webinar and come away with a headache?

That's what I thought.

Of course we also have the opposite problem at times. Some people like to make it SO simple that all you have to do is buy their product or implement their program and voila, you're service oriented. How many of you have gotten that presentation?

Like most things in life, the answer lies somewhere in the middle. Yes it is complex and yes it will take time and commitment to achieve ultimate success. But SOA is not something you just do. It’s not a project you assign to someone to tackle. SOA is an iterative process that involves the entire organization and there are successes to be had along the way. It is the culmination of these successes that ultimately results in overall success of your SOA initiative. Taking on too much at one time or trying to big bang or fast track your way to SOA will ultimately lead to failure. So again I say, "Keep it Simple, Stupid".

In a series of posts I will lay out a simple plan for achieving iterative success. Don't take this as a recipe to follow exactly or as your definitive guide to SOA. Instead take it as a blueprint of sorts; a series of checkpoints and milestones that can be tackled iteratively. Each one comes with its own success, some small, some big. Remember, something doesn't have to end world hunger to be classified as a success. Sometimes it might be nothing more than knowing more today than you did yesterday. As long as you are moving forward down the path.

Step 1 - Stake in the Ground
We'll start right off with one of those simple successes. It may not seem like much, but simply making a decision to address your issues is a success. Of course this needs to be more than 1 person making the decision. It has to be a top down decision stating that the efforts to address the issues and work towards a SOA will be supported both verbally and financially.

A key piece of this step is also to understand the issues at a high level. This understanding has to go all the way to the top. You don't need to know or understand each and every issue in exhaustive detail or how to solve it though. That will come in time. Simply recognizing that there is a problem is a big step that is often overlooked and the decision to support an SOA initiative has to come from that recognition and not from some charitable management offering (e.g. "Well IT wants to play around with some new stuff so let’s give them just enough leash so they'll go away").

A formal speech or email from the CIO (or equivalent) that expresses the commitment and support of the effort is an important milestone. This will not only express the top down support, but emphasize that it is not a passive or low priority initiative. This will go a long way in motivating everyone to participate or at the very least not hinder the effort.

_______________________

Next up: Education

SOA: Looking inside IT

2007-05-31T11:38:00.000-07:00

Usually when we talk about SOA, we talk about two distinct groups: Business and IT. With that, we discuss how SOA impacts and applies to each of these groups and further go on to try and figure out who is more accepting or less accepting etc. The more I see SOA initiatives first hand, the more I start to wonder if these groups are too course grained.

Its very natural for us to settle on only two categories. Its easier to talk about things as if they were black and white, on or off, your fault or my fault. Most of the time this is done to simplify a problem so we don't get bogged down in the minutia of the gray area. For this topic though, I feel that polarizing the participants into two categories obscures a very important piece of the puzzle.

We use the term "Business" to refer to all non-technical functions and resources and "IT" for everything and everyone else. While Jeff Schneider did a good job of breaking down the Business for the purposes of SOA interaction, I feel that IT needs some breaking down of its own.

Within the IT category we have two distinct roles. The first role is that of the enterprise architect although they need not have this title to be in this role. The folks in this role typically see the big picture. They understand the value of design and architecture and strive for consistency and foresight. This group usually sees the value of SOA much in the same way the Business does, although they see it with technical goggles on.

The second role is that of the project teams. This usually consists of project architects, project managers and developers. This group is firmly based in reality and even if they see or could be made to see the value of SOA, they would point to the 3 projects they have going that all have to be done yesterday, shrug their shoulders and laugh about the crazy SOA guys over a beer.

Of course it takes both of these groups working together in some fashion to make any progress towards a Service Oriented Enterprise. It means nothing to have your EA group creating SOA strategies and processes if they don't have the means with which to realize any of it. Implementing registries and documenting business processes are a great start, but unless the project teams are integrated into the process, all you'll be left with are nice diagrams and a bad case of ERS.

So when you are addressing the issues of your SOA initiative, don't blindly look at IT as one big group that needs to get their act together. Rather you need to focus on how you can facilitate the coordination of these two distinct IT roles.

Component or Service?

2007-05-31T11:15:00.000-07:00

What exactly is the difference between a component and a service?

This is a question that popped into my head when reading a response to Todd Biske's blog entry Challenge of Data Services. In the response, Udi Dahan comments that access to data should be done through components and not services. But what exactly is the distiction that Udi is making here?

After trolling a bit for a definition of a component, I came across the following on wikipedia:

A software component is a system element offering a predefined service and able to communicate with other components.

Clemens Szyperski and David Messerschmitt give the following five criteria for what a software component shall be to fulfill the definition:

Multiple-use

Non-context-specific

Composable with other components

Encapsulated i.e., non-investigable through its interfaces

A unit of independent deployment and versioning

A component is an object written to a specification.

A definition of service comes from ServiceOriented.org:

A Service is a callable routine that is made available over a network. Services have well defined interfaces (inbound and outbound).

While you may argue the exactitude of all these definitions, its pretty easy to see that a service and a component are very similiar if not indistinguishable. In fact it might be that the only difference between a service and a component is its accessibility via a network.

One might argue that a service is nothing more than the manifestation of a component on a network. To make this point I ask the following question: Does a component, written as a Java class, suddenly become a service when it is made accessible via an EJB or a Servlet or a Web Service? Or does it remain a component which is now offered as a service?

Of course you could still argue that the component was always a service from the point of view of other local Java classes.

I believe the Service Component Architecture puts its best:

SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces called services...

Given all of this, if data should only be accessed via components and not services, then what happens when my Java implemented service needs access to data that is exposed via a .NET component? Do I re-write the component in Java and maintain both implementations? Or would I make that component a service and be done with it?

Thus I see no reason why data access can't be done via services.