The Analyst's Perspective

Stop Doing the Work of the CMS! - Part 1

2009-04-14T05:18:00.000-07:00

Picture this: you have a flat tire and you pull over to change it. To achieve your goal of changing the tire you perform the following tasks:

1. Put the jack under the car
2. Place the wrench on the lug nuts
3. Crank away with (on) the wrench and remove all of the nuts
4. Pull on the tire
5. Attempt to lift the entire car up by yourself
6. Step back and observe your conundrum

Did you notice the missing step? (Lifting the car with the jack, anyone?)

So what is the moral of this story? Don’t attempt to lift the car by yourself when you have a fully capable tool that can help you. The same can be said for content management systems – don’t attempt to “create” key activities of the information lifecycle on your own, let the tool do it for you.

In my previous post, E-mail is NOT a collaboration solution, I talked about why collaboration through email is a bad idea and offered some CMS alternatives to this [horrendous] practice. Today, I’m going to cover a few initial recommended practices with your new CMS so you’re not trying to lift the car without the help of a jack.

Note: the following recommendations are based on the assumption that your CMS has versioning capabilities and they’re enabled.

Recommendation 1: One instance, one file – period. Do not physically label versions of files that are stored in a CMS in the filename.

For example, let’s say we’re creating a new Product Manual for a VCR (remember those?). When the Manual document is created and loaded in a CMS it’s automatically assumed to be version 1.0 (or 0.1, 0.01, etc. depending on your CMS’ configuration). So, always leave the “ver X”, “vX” (where X is typically a number) out of the file name.

Why?

Because the CMS is controlling the versions internally behind the senses. For example, if you have “Product Manual v2” and it’s iterated on multiple times, you might have 10 versions of “Product Manual v2”. How do you explain that to your consumers?

“Mike, check version 10 of version 2 in document version 8.”

Mike is thoroughly confused at this point and doesn’t want to use your document at all. Instead, call the document “Product Manual”, let the CMS control the versioning. When it’s ready for public consumption publish “Product Manual” and let the incremental versions be contained behind the scenes.

Next Post: Recommendation 2: Communicate revisions inside of the document

E-mail is NOT a collaboration solution

2009-03-12T07:16:00.000-07:00

How many times have you received this message in your Inbox?

“Good morning everyone - attached is the [insert adjective here] document – please review and send me your comments by COB Thursday.”

Before I say that these messages annoy me, let me add some context to it first. The following statements are all based on an assumption that you have some sort of document management tool available to you. (If you are reading this, and say that you do not have one available, I strongly recommend you check out Google Docs – it’s free!)

So, with that being said, if you just want to see what I have to say and I’ll never see your document again then I don’t mind the message (well, too much – intellectual property is another post). However, if you (sender) expect to take feedback, incorporate it into a new rendition/version of the document and republish it later, then I am super annoyed by your message.

Why does this practice me bother so much? Because I know that you’re (sender) going to send another message 5 days from now with a new version of the document. That means that I now have 2 messages in my Inbox, 2 versions of the document and a whole string of emails from other people whose opinions aren’t relevant to me or the subject at hand.

Despite my obvious annoyance with this practice, this isn’t the main reason to avoid this practice. Rather, it’s critical to capture all of this context in a way that is traceable, searchable and easy to access (have you ever tried this in your Inbox?). Remember, it’s all about the business value, not just the last version of a published document - business value is realized through the creation and lifecycle of a document (content).

What is the solution? Simply put – collaborative spaces with document management capabilities. Google, SharePoint, OnBase, Documentum, you pick – just make sure it has notification, check-in/check-out capabilities and the ability to publish multiple major/minor versions of the same material.

Here’s a simple questionnaire to look at when crafting an email. If you answer YES to any of these questions, please consider a collaborative solution instead of attaching that document to an email.

* Is there more than one recipient for this message (that has an attachment)?
* Do you expect to receive feedback on the content (document) attached to this message?
* Do you plan on publishing another version of this content (document)?
* Will this material be used in the future by anyone in the organization?
* Will the context of the content/feedback be lost entirely if the email is deleted?
* Is the material stored on a file share or someone’s independent machine?

A Valentine’s Delivery Story

2009-02-13T18:21:00.000-08:00

Today, as I walked away from my most recent engagement, I was reminded of what makes IT solution architecture and delivery enjoyable for me. It’s hearing customers rant about:

* Reduced operational costs
* Improved service delivery
* More effective use of limited interactions with constituents

Right? No. Sure, all of those were present after the solution was delivered but those didn’t top the list. Instead, here’s the one that got me:

“I’m going to give you a valentine!” - as stated by the person who had the longest list of pain points just a few months ago.

It’s not always about the 1s and 0s, or the 1s + the number of 0s behind it. Today it was simply about delivering a technology solution for someone to make her life easier.

CIO.com and iPhone/iPod Support

2009-01-19T23:30:00.000-08:00

I was very, very surprised to find that CIO.com, the flagship website for "Business Technology Leadership" (that's from their site), didn't automatically detect my iPod Touch and re-skin accordingly. Now, CNN, ESPN and most other "mainstream" sites do this automatically so I don't have to be inconvenienced with constant strolling, but not CIO.

Reread their tagline - it's interesting (and ironic).

Great Analysts Do Solution

2009-01-13T10:57:00.000-08:00

“Just tell us what you want and we’ll tell you how” - the old adage of “what” vs. “how” in the IT mantra.

Today I was reminded that effective (great) solution analysts do both.

[I think the architects just threw something at my head from down the hall]

Let me clarify a bit…

I don’t think that solutions analysts need to know the extreme interworkings of a solution but they had better understand the conceptual aspect of the solution, and, most importantly, know what it can and cannot do. You must be cognizant!

Take for example a custom-development system vs. one that is available off the shelf (SaaS more specifically). When eliciting requirements it is critically important not to lead stakeholders down a path that will be impossible to fulfill with the defined solution. (read: you’re solutioning with the team) So, if the winner ends up being a pre-built package then it’s important to know the boundaries as you’re dance with the stakeholders. Otherwise, there’s a solid chance that you’ll never be able to fulfill requirements that you pulled out of the stakeholders.

[I think the PM just threw something at me – we wasted time and irritated the stakeholders because we’ll never be able to deliver this functionality]

So, in summary, understand the capabilities and constraints of a solution early in the game – even in the requirements phase.

New Gmail Look

2008-11-20T09:16:00.000-08:00

Literally, 10 minutes ago, I walked away from my laptop and had Gmail loaded in my browser. After returning with my hoagie, Gmail had a weird look. All the sudden - Gmail throws a nice box up at the top of my screen that says "Our look has changed, check out the available themes".

Awesome!

Not the themes, per se (although I do like them), but the fact that Google can roll out a major enhancement like this without an explicit and direct communication to all members. Can you picture how much discussion (and scrutiny) this would go through in corporate America?

Not Google, that's the beauty of their products - they roll it, tell you about it and most importantly - give you the ability to go back to the same old if you desire too. Now that's usability...

Oracle SOA Suite Training: Day 5

2008-11-07T12:00:00.000-08:00

Security, policies, securing policies with processes and policies. Information overload at this stage, I gotta leave this one up to the Ops guys to handle.

Again, as I mentioned before - NFRs play a big part in this one.

Oracle SOA Suite Training: Day 4

2008-11-06T20:00:00.000-08:00

Day 4 – real-world stuff:

* business rules
* human workflow
* integrating java apps

Great agenda – let’s finally get a look at how this technical solution will work for the business world.

Business Rules are a small component of the SOA Suite. I love the concept – create an abstracted layer for business rules so business users can make changes freely through a nice user interface without the need for a code change. Great – great concept!

Unfortunately, the Oracle solution will only get you half of the way there in my opinion. To say the UI is more unfriendly than the rest of their apps is a safe statement. It looks like a product that they acquired years ago and never really invested anything else into it. Binary files behind the scenes, no web services hooks – pretty ugly. However, it does have an API so at least you can put the lipstick on the pig. (See InRule.com for a more friendly BRE)

Human workflow – awesome stuff. Unfortunately we didn’t get very much into this topic because of an all-day lab exercise. I need to continue to explore the interface to approving or completing tasks within the product. I couldn’t tell if the dashboard I was working through in a lab was a free lab add-on or part of the SOA Suite. I was pretty impressed with the technology’s ability to query a directory for escalation paths – that’s neat stuff, especially when you get into the SLA conversation.

Java integration – it’s doable, right in BPEL. Nice stuff, but not my cup of tea…

Oracle SOA Suite Training: Day 3

2008-11-05T20:00:00.000-08:00

Day 3 – on to the bulk of ESB and SOA, specifically:

* adapters
* data transformation services
* exception handling

Now we’re on to the bulk of ESB and SOA. I’m thoroughly impressed with JDeveloper at this stage. While the tool has a few quirks and is not the most defect-free of its time – it is a super powerful tool that does some really neat things.

Today we examined a few of the built-in adapters that Oracle provides out of the box with the SOA Suite. I was impressed, there are a quite a few that I can see being used pretty regularly: file, database and copybook were the ones that jumped out at me. Of course they had a vast amount of adapters for the Oracle Applications suite but we didn’t play with them because of the isolated training environment.

We used JDev to build some quick and nesting data transformation which was pretty cool. I could have used that a few months back. We took the input from some flat files and mapped it to inputs in the process which was used to drive decisions further down the process road. Neat stuff…

As far as exception handling goes, we watched more of a lab demonstration vs. talking about why, where and what to do with them. Not much additional on that topic, wasn’t covered all that well.

The ESB product is pretty cool, you can set up notifications for dropped messages, etc. pretty neat stuff. Plus, its integrated with JDev real well, you can build an ESB projects seamlessly in JDev and build/deploy in no time. Great stuff… Now, if I could just test all of this without using Oracle Application Server I’d be a super happy camper.

Oracle SOA Suite Training: Day 2

2008-11-04T20:00:00.000-08:00

Day 2 - BPEL 101 [finally, the reason I'm here] We covered:

* developing a simple process,
* orchestrating a few services with BPEL
* creating parallel process activities.

As we walked through a different synchronous vs. asynchronous process and consuming services offered through a PartnerLink, my initial thought was - man, how important NFRs and services agreements are in this "SOA" world.

Picture this scenario - I order a product online which kicks off the "Submit Order" business process (via BPEL). During "Submit Order" the process makes an external synchronous call to a shipping service and waits for the response. However, the shipping provide is having issues and doesn't generate a response.

"Submit Order" is now holding and waiting - yet not submitting.

Do we have an agreement in place with the shipping provider that states they'll respond in less than 1 minute? Do they guarantee a response?

Did we capture the expectations of the fulfillment team during our elicitation sessions? Do they care that it might take 2 days to actually complete "Submit Order" or do they think it's instantaneous?

It seems to me that NFRs have more importance in the SOA and BPEL worlds.

Oracle SOA Suite Training: Day 1

2008-11-03T20:00:00.000-08:00

Oracle DC facility is nice; it is in the heart of a tech-centric area called Reston that’s 15 miles west of DC.

Day 1 consisted of SOA overviews and installing the various pieces of the SOA Suite . Nothing real noteworthy on Day 1 except that everything runs on the Oracle Application Services (read: scary).

We did cover top-down WSDL-driven services vs. bottom-up services – cool stuff, same old Interface-driven development but much, much easier with Web Services. Does any actually create an object from scratch now? I doubt it... JDeveloper (as I'm sure most tools do now a days) allow you to right-click and create your entire Java source from the WSDL. Great stuff.

Wonder if WSDL black belts run the world in the future?

Requirements and Design

2008-10-17T12:13:00.000-07:00

I have recently found myself on an engagement where the is no clear line between requirements and design. Both activities tend to bleed together which creates a level of requirements complexity and they quickly become unmanageable.

I have read many books on requirements (including my personal favorite which authored by a good friend of mine Daryl Kulak, Use Cases: Requirements in Context) and have been producing them for the better part of a decade now. In most of my reading, authors typically stand firm on the idea that design is a separate activity and should be isolated from the requirements creation process. I have found that most effective practitioners will also agree with this approach.

And, while I tend to agree with this as well, is this a stance that can be taken in all organizations? More importantly, is this approach feasible when working with a COTS package?

So, while requirements generation and documentation is without a doubt an art (vs. a science), how much "creativity" can be embedded in requirements without bleeding into design?

Home Remodeling and Requirements Elicitation

2008-02-27T08:00:00.000-08:00

Two relatively different topics, right? Not so much it turns out… Recently, after a long weekend of remodeling our master bedroom, I was reminded how important the requirements gathering process is, even in everyday life.

After my wife and I painted and rearranged our entire bedroom, my wife decided to “de-clutter” the room (I would like to thank HGTV for this new concept). However, in the process, she didn’t ask which items in the room were important for me to have quick and easy access to. So early Monday morning when it came time to leave on a business trip, I couldn’t find my watch, or my passport.

Me: “Honey… where is my watch?”
Wife: “In the nightstand!” (she responded in a frustrated tone)

Nightstand? For my watch? Hmmm… Of course, I thought… (insert sarcasm here)

I quickly figured out that my wife made a mistake that IT team have traditionally made. She assumed that she could hide all of my personal belonging in the effort of de-cluttering our room. However, she never asked which of the items were important to me to have easy access to. So was this an ill-willed effort to make my life more complicated? Of course not – she just simply never gathered requirements from me (the end user).

So, before you attempt to bury that application functionality deep in a menu to make the screen look cleaner, make sure you talk to the folks that are using the system to see which functionality they need quick and easy access to.

And honey - the room looks great...