IT Governance & Business Analysis

Hey, if you're a customer with IT needs, just throw all of your ideas up in the air, and pipe each one of them to IT to be built. Heck, you're the ones that know what you want, so why should we evaluate and contradict your demands? You're the one paying the bill; it's not up to me to challenge your demands. You want a solution that knowingly will break a legacy system or process - great! We'll design, code it, and deploy it right away. And ya know what, we'll even throw in a two-pack of Sham-Wows(c)!

What are our customers really seeking with its software requests? Do they even employ sound, skilled business analysts capable of creating system requests that are well evangelized, correct, and show good ROI?

Hmmmmm, why should I care? If they want another widget, we'll give it to 'em, right? Wrong!

I can't believe how many systems I'm seeing recently that have had so much functionality bolted onto it that it's seemingly impossible to maintain. Customers surely know their business, but without trained analysts to handle at least some level of process re-engineering to understand and consider all angles of a software request (be it a new system or an enhancement), these customers cannot possibly expect IT to decipher and build exactly what's needed. Sure, they'll get what they asked for, but how responsible with public funds are we being responding to needs in this fashion? Not very...!

Well thought out business demands should come from a study of the existing IT system and all adjacent systems that it hits. Once I understand and can speak clearly to the new request or enhancement needed, it needs to be well documented and communicated. Beyond selling the idea or concept to IT governance, the BA needs to be able to efficiently and exactly convey business requirements to feed the dev team. In a very agile environment with slim resources and heavy service desk maintenance demands with those same sparse resources, we need to summon exactly what information is required to create a user story...JIRA is an example of a powerhouse platform to create user stories and garner exactly that support information needed to build the solution. Giving the BA that boundary helps assure s/he provides exactly what you and your team need to succeed. Don't forget to include a blurb on each story's "conditions of acceptance".

If you're anywhere near a public sector business, you've got to read Extreme Government Makeover by Ken Miller. Inspiring and so very, very perfectly stated. Remove the twists in your systems pipes...Another post coming soon on this topic.

Been too long

It's time to start blogging again. Yeaaaah.

Projects with a shelf life

Now, there's a concept...but for many of us, we're left implementing a solution atop a partially immature platform. There's money to spend and time is of the essence, so gimme something now!, is the mantra. Still, as a consultant and technology liaison for customers with little to know in the space, it's in the best interest to assure technology solutions sit squarely within the reach of the customer's IT expertise if they intend to own the product at turnover. Moreover, it's simply not feasible for most to expect to ramp up 3-5 fold in order to take on a new system that requires a massive shift in support.

Be fruitful with the customer and be able to sharply explain the good and bad of technology choices. Recommend the right solution, and don't settle for less. Of course, your customer is always right, but help educate them...help them make a better decision, help them with proofs of concept to sell to higher management....make them a salesman for your services.

To he who says software has an 18 mo lifecycle and must be replaced is just unfair I think. There's plenty of working implementations out there in .Net 2 and 4 that exhibit higher customer value with minimal support components. All important is the role of technical architect on the project. Fail this milestone and you're done for. I guarantee it. I want to revisit this topic next.

SOA what?? Part II

OK, so it's been nearly one yr since I posted Part I...pretty crazy I didn't consider doing a series on the topic. Anyway, here's some further discussion about the concept of Service Oriented Architecture...

First off, traditional web client applications can rarely be generalized as a thin web client. Like MS Silverlight, what you end up with, using a set of solid WCF services to harness the backend is nothing less than a SOA application taht just so happens to front a rich interactive application (RIA) interface. Calling a Silverlight or Flex app a thin client is akin to wearing a McClaren jacket at a tour through the Maranello factory. So, SOA in and of itself is merely teh notion of using an agnostic set of services that perform complex business logic; the front end application merely consumes what's thrown at it.

Consider your fancy new Silverlight app using Entity framework and WCF services throughout...you've got adjacent customers that could surely tie into those services and solve their own sets of business needs. Data Exchanges are merely a consumer of SOA - such an interface (or exchange) can be created through simple WCF web services or through more complex varieties.

Imagine that Contoso Shipping has this new Silverlight application. Consider the various adjacent systems that interact with the shipping provider. The distributor to the cardboard box maker could use a look-see into your organization in order to know when to send more boxes to you. Our cardboard box maker company uses its own sophisticated, local software solution for its work mgmt, and isn't about to create something and get the shipping company to expose its data.. Instead, our shipping company merely partners with the box company. In doing so, a service contract is setup and those wcf services that provide the interfacing needed (likely existing services that already poised doing other work) are directed out through this new web service. The box company has the bulk of the work from here - they need to extend their local solution (system) to consume these services, transform the data structures coming across and do some analysis. The output sends data points to their system, all the while the system of record remains internal to the box company, but the shipping company gets real-time data from the box company about its # of boxes coming, etc, etc. Make sense?

In this context, a service oriented arch exists that can be consumed by other (dozens) of client applications in order to make use of the data constructs. The service provider merely exposes and publishes its web services to get at the data, and its approved partners get access to the data for consumption, etc.

The interesting part is that of the analysis needed up front to properly put business and technical req's together to facilitate a) exposing a usable service for potential or known users, and b) providing the data exchange using a broad enough declaration of services that can be consumed by the masses. The last, most complex part is that of reconciliation - either the servicing party or the client party must be responsible to resolve data issues that can and will exist between the two parties. In my opinion, it's always easiest to put the burden on the client (consumer of the services). But, this depends on your system of record...if the State, let's say, exposes criminal data to the state counties for use, it likely expects that this is the system of record, and all such edits need to exist in this single system. So, as the State body, we can't expect that the counties will update this system in a fire and forget mode. Counties need to resolve conflicts in the data, e.g., you send me this, and it doesn't match my interface schema or conform to its pre-justified rules, it's kicked out, and you fix it...or, you send me a case record, but some pre-requisites fail, we abort the data exchange, and the county must resolve. The state in this context expects that the local agencies get good data into the system. One step further, imagine the local agency being satisfied with its own local system; they merely have a data entry person stuff data into the system of record (the statewide data stores)...if this person puts bad data in, they resolve it. If not, garbage in, garbage out, especially when in a case like this, reporting is so critical.

A first experience with NLP (Neuro-Linguistic Programming)

A good friend introduced me to this concept by suggesting a give it an honest try. I'm in a good place with myself and decided to have at it. Leaving the session on Tue, I felt changes and the next day I noticed those same old, ugly thoughts that had plauged me in meetings, during interactions w/colleagues and bosses, and in home situations were a lots less stressful. It is truly from within that the NLP thing works, I get that. I have to believe and continue to see and act on the transformation, but honest to goodness, I thought this was hogwash at best going in. I had to be completely vulnerable and thankfully I did;).

John Grinder and Richard Bandler founded the NLP methodology, it appears, and I am soaking up bits of it this week from the Web.

My personal style of learning and adaptation has always been through reading, reading, reading, and reading some more....then writing it all down for absorption. I really see now how past experiences that have binding effects on me can be altered - not brainwashed, I guess - bu made to contain these new "resources" rather than the old junk. I guess I harvested out the old garbage and implanted anew. That's the best way I can describe this. The gal I worked with for those several hrs sure knows what she's doing and I appreciate that whole journey.

How do I blog about this stuff, this intimate stuff that's unfolding, and make it apply towards my goals of this blog? I'm starting to figure it out.

I'm halfway through Crucial Conversations...a great text. I'm actually listening to it in audio form. I am not a very good learner in this format, so we'll see. I like to see and feel the words on the page or in a document on my iPhone....nonetheless, this is another bit of homework I've given myself - this book, that is...

To want growth, you have to believe in yourself

I'm shockingly learning more about myself as I get into my new found kick (for those unaware, I've sought professional support, coaching, if you will to help my personal and professional power)...I had a very interesting experience last night that honestly helped unlock past emotions to really surface why I am a certain way - feelings and events that led to what I am today - an almost 40-somethin' character that realizes (luckily) that I need to change how I react to professional settings and how I can enrich my life as a father and husband.

It sounds kind of cooky, I'll admit, but I just have this sense of value, worth, security, and compassion that I couldn't explain a few days ago. I need to learn more about this thing (we'll call it for now), but I'll share more in the coming days. It's truly life changing - one building block at a time. But, I'm open, vulnerable, and willing to adopt change, spill my guts...I want to feel better about taking on new challenges in life, learning how better to negotiate with clients/peers, being a better role model for my young daughters, a better hubby, and advancing my career.

Is it an early midlife crisis, this life coaching desire? Nah. But, I'm thankful to those nearest me who believe in me and for me having the guts to believe in myself and reach out for external support. Pretty awesome discoveries so far.

Still seeking an old book called, I'm, OK, You're OK. I'm reading Crucial Conversations right now. Love & Logic will be next.

A novel idea! A novel about Project Management

I just finished (today) a terrific novel (of all things) called "The Deadline - A Novel About Project Management" by Tom DeMarco. It's a 1997 read that absolutely blows my mind. It considers basic principles of management in ways and in relationships I simply didn't consider before reading this 300 pg short book. The author illustrates in first person prose in real terms how to put simple change in place - and we're not talking about PMBOK 4 101 here....

The author gets into intimate details about where problems in projects (systems) reside, how to solve them, and more importantly for me, shows you how it's really done all within the confines of a myriad of characters, actions, and personalities. This book illustrates quite openly about how management involves four key things: heart, gut, soul, and nose...among many other great points that the main character collects throughout his tour of duty. I'll note those in a future blog post (I tend to take notes about my findings to paper since I don't memorize key points in books as easily). I know someone that sure can do this though...like a human journal, he is!

But for now, take my word that this book is as relevant as ever. Tom even has some keen insight in this era (some 14 yrs ago now) that is spot on with today's complexities building and deploying software. That Lahksa Hoolihan character is engraved in my head - engaging, cunning, and beautiful all in one;).