SOA Lifecycle

I read an article today on SearchSOA that was a pretty comprehensive review of the SOA Lifecycle. While I’ll be the first to admit that alot of ink was dedicated to concepts that are seemingly common sense, there are several salient points worth noting in this article.

The first point of note has to do with SOA governance. Since an SOA is ultimately a portfolio of business capabilities (some specific to your organization, some external to your organization), governance becomes more important than ever. Back in 2001, I wrote an article for PerfectXML.com that delved into the nascent domain of SOA management and governance. The idea is simple, the more assets you reuse and the more services you incorporate into your applications that are not under your direct control, the more important governance becomes. While the promise of increased reuse coupled with shortened “time to application” periods are very attractive propsects, there is a price to be paid in terms of application reliability and stability. When there is a problem, which service is as fault? Who is responsible for fixing the problem? Proper attention to infrastructure and portfolio governance is the only way to help ensure that your SOA is ready for prime time. Implementing an SOA without a well structured governance layer is a formula for disaster.

The second noteworthy point relates to the focus on service consumption as pointed out by Forrester’s Randy Heffner. His following comment are words architects should live by.

"Focusing first on consumption puts you in the proper mind set for doing SOA because that should be the default approach," Heffner said. "It puts you in the mindset of first achieving reuse."

Your SOA only has value if it makes available services people need and presented in a consumable form (like a Ratchet-X plug-in – shameless plug). When I was a developer, we used to start our project discovery process by asking users what kind of reports they needed. The idea being that you first find out what information users need and what they plan to do with it before you worry about features and screens. Heffner’s comment is an SOA-updated version to that approach. Find out what people need and how they need it presented before you focus on service design.

The last important part of the piece pertains to Dana Gardner’s comment regarding shortening the lifecycle period. Unlike traditional applications, SOAs are living, breathing and most importantly, dynamic organisms that are subject to frequent refresh by design and necessity. Dana’s following comment is important to keep in mind when managing your SOA.

"Your services are going to be dynamic, so you're going to want to have a fairly frequent refresh or replacement of specific services based on requirements," Gardner explained. "At a higher level of abstraction, you're going to have changing business processes that those services support because you're going to want to adjust and amend on a fairly rapid basis for efficiencies. You're going to want to give more people who are close to that business process some say in how that process can be amended and improved iteratively over time."

I Gotta Be Me...

I guess year end is the time to “spring clean” one’s virtual identity. Over the past week, I’ve gotten a barrage of emails inviting me to various social networking sites to verify that I know someone, befriend someone else, or simply update my contact information. Plaxo tells me everyone is doing it this time of year so it must be true.

The point is this, while I’m happy to verify, befriend, endorse and vouch, I do resent having to create and maintain multiple online identities. I’m not a teenager who winds away the hours online interacting with the rest of the world via the persona that suits my particular mood at any one time. I have one identity, one brand if you will, and that’s all I want to maintain regardless with whom I’m interacting. Sure, I want a way to segment that identity so my business associates need not concern themselves with what side dish I’m bringing to mom’s for Christmas dinner, but all-in-all, I want one place to manage my online identity.

This problem first became apparent to me back in the day when I would repeatedly enter my address, date of birth, payment credentials and other personal information into almost every website I visited. I thought to myself, shouldn’t the web be the one place where I shouldn’t have to re-key data over and over again? This is why I was a big fan of Microsoft’s Passport (now Windows LiveID) and Hailstorm initiatives. The “one me, one identity” concept was quite appealing. Now we can debate whether Microsoft as a company or their identity management plan was right for the task (I personally have no problem with Microsoft fulfilling this role considering their software drvies my computers, mobile phone and game console), but the bottom line is I shouldn’t have to maintain a different set of credentials everywhere I go. Could you imagine having to maintain a different license for every state you drive through or a different credit card for every store and restaurant you visit?

Now Google is trying to fill the void with Google OpenSocial and Google Profiles. While the information tracked by these services is initially pretty basic, it’s easy to see where this can go. I for one am happy to see this development and hope it happens. Why Google is any less “frightening” now than Microsoft was back in 2001 is a bit beyond me but I guess a lot has happened since then. Be it the acceptance of the software as a service concept, more sophisticated security and fraud detection systems and the explosion of social networking, now might be the right time to finally implement the unified identity concept. Let’s hope so.

Do You Want Auto Updates of Acquired Data?

When pitching Ratchet-X, I’m often asked the following question; “Once I paste data into an application screen, will that screen be updated if the data changes at the source?” Currently, the answer is no. But there’s no reason it couldn’t assuming this is truly what customers want and are willing to accept the manner in which we can do it. Allow me to lay out the issue below and I welcome your feedback regarding this concept.

Currently, after data is pasted by Ratchet-X into an application screen, the data is “disconnected” from the source. This means if the data changes at the source, your application data will not reflect the change. Why is this? It’s because Ratchet-X is currently only aware of the data that is actively available on the desktop. In other words, the only data Ratchet-X knows of is the data that resides on application screens to which you’ve navigated and currently have open. While Ratchet-X does have an existing mechanism to automatically query this active data and perform a refresh, it doesn’t have a way of refreshing data that it has previously acquired.

Based on customer demand, we expanded Commander’s Clipboard function and renamed it the Commander Task List. One of the new task list features is the ability to export data to disk so it can be reused at a later date. Well, what if we were to expand this feature so that data that passes through the task list (which includes all the data that is pasted), is automatically saved on a server. Once that data is stored on a server, it then becomes a discrete data object that can be have a number of functions performed upon it independent of the application that requested or houses it. One of these functions could be source monitoring for the purpose performing data updates.

Let’s look at the following example. Imagine you’ve just pasted a credit rating for a customer into your accounting system. Currently, that rating will not be updated until you explicitly navigate back to that customer’s record and ask Ratchet-X to refresh the data from the source.

However, we can expand Commander so that it stores the pasted credit rating on a server and be given an instruction to monitor the credit source on a monthly basis and notify you when the rating changes. When it does, you will be notified within Commander at which point you can elect to go to that company’s record in the accounting system and paste the updated credit rating.

At the end of the day, this data is your data. Whose server should it live on? What functions can be performed upon it? How often? At what cost? At RatchetSoft, we recognize that information is one of an organization’s most critical assets so we are vigilant about allowing only the owner to control its flow. However, as customers look at Ratchet-X as being more about structured data trafficking and less about cutting and pasting, we get bombarded with these kinds of advanced data processing requests.

Is this a feature you’d like? Should it be a priority? What do you think? If you have an opinion, leave a comment or send us an email at info@ratchetsoft.com. I look forward to hearing from you.

Originate or Replicate Data?

Ratchet-X is an innovative technology that allows people to transform existing Windows and browser-based applications into mashups. I’m often asked by customers, when data from these external sources is mashed in, should it be replicated in that application’s storage of record? The answer is…it all depends. If you are querying external sources for the purposes of compiling a composite view of an “entity” to make a decision, the answer is probably not. However, if you're querying the external sources as part of a data entry task where the acquired information needs to become part of the software you’re using, the answer is unequivocally, yes.

Here are some simple guidelines we use when advising customers regarding the “originate or replicate” issue. Replicating external data is recommended when any combination of the following conditions is true:

1) The performance (speed and availability), of the external sources is unreliable – get the data while you can.

2) The data acquired needs to be part of the system to support backend reporting functions. Downstream functions such as reporting will not have access to the data you’ve mashed in through Ratchet-X unless you replicate the data.

3) The source data is not prone to frequent change.

4) There is a “per access” fee to access the data at the source. However, if the data is subject to frequent change (like a stock price), you may be forced to absorb the fee in exchange for timeliness.

Conversely, if these conditions do not apply, then we encourage you to access the data from the source on demand.

Ratchet-X and Windows Vista

We've recently received a flurry of questions regarding Ratchet-X support for Windows Vista. Here's the current status. Ratchet-X does work under Vista in terms of recognizing screens, extracting and pasting data. The current issue we have is that the alert button (the button that appears in your integrated application's title bar), does not render properly under Vista. While we can implement a quick fix, since only 2% of our site's visitors and downloaders are Vista users, we've decided to take this opportunity and bite the bullet on a bigger issue we've been deferring for some time."

We've had a number of users express a preference for the alert button being "appended" to the integrated application window rather than inserted it into the title bar. If you've ever used WebEx or GoToMeeting and with an IM package, you've seen this technique employed. So, based on these preferences and the Vista rendering issue, we've decided to tackle the problem in one fell swoop.

This being the case, we anticipate certifying Ratchet-X for Windows Vista in early 2008 (Q1). If you have any questions or comments, as always, don't hesitate to contact us or post a comment here.