Skip to content

Posts tagged ‘enterprise’

Agile: The Most Overused Word in IT

A quick glance at the dictionary gives us a definition of the word agile – “marked by ready ability to move with quick easy grace.” The IT community has co-opted this word and extrapolated a meaning that is really beyond description. Of course, what else were we supposed to do?

Much comparison has been drawn between building software and physical construction (e.g. building a house). But this comparison really isn’t fair. While it’s true that it’s extremely costly to make changes to a building after it is erected, the same multipliers used in that industry cannot be applied to software. Seriously – have you ever had to bring a demolition crew in to remove a section of code? The delete key is our wrecking ball.

At some point, I’m sure a manager looked at this software construction like building construction parallel and said, “I need you guys to work in a more agile manner.” And there it began. Sure, there were puzzled looks in the conference room, but then they all went back to their war room or desks and started figuring out what the manager meant by agile. Today, we have a half dozen agile methodologies that address this perceived need to move fast. Each of them has their own caveats of “this may not be the best approach for you.” Unfortunately those sections seem to be often skipped.

The Software Development Life Cycle you choose for your project should not be dictated by whichever magazine article is sitting on your desk at the moment. It is a choice that needs to be carefully made based on your entire situation. What is the makeup of your team? Do they work best on well-defined tasks or are they better when left to find creative approaches? What is your relationship and level of involvement and commitment with your customer? What type of project is it – are you solving a well defined problem or is further research required?

My parting thought for today is a continuation of the last paragraph’s them – ask questions. If you are the team lead or project manager, your value comes from applying the experience you’ve gathered from past projects. When your customer or manager makes a broad statement, dive into it and understand what he is asking for. You will then have a much clearer shot at success, no matter what methodology you choose to deliver it.

Building a Platform – Reductive Feature Design

I have spent a lot of time over the past year (really over the last 20 years) looking at the keys to success and failure that have been experienced by certain technologies and platforms. Many product organizations take a kitchen sink approach to delivering features in their product. This can lead to a “jack of all trades, master of none” perception in the marketplace. It can also confuse users as to exactly a product should do. On the flip side, you have groups that release products that seem to be incomplete.

Right now I am a fan of Apple and its approach over the past decade to personal electronics. They seem to have taken the approach of delivering a chunk of value, letting people adjust to it, and then have the customers say “it would be really nice if this thing did x.”  iPhone OS 3 gave us the ability to cut / copy / paste. This function point has been ubiquitous in computing for the past 2 decades, and yet Apple decided not to include it in the original release. The same is true with multitasking – even the Palm platform in the mid 90’s allowed a form of multi-tasking (such as it was) and yet Apple it’s waiting to the 4th generation of it’s OS to make it available.

When you first look at this, you may think “Gee, they just wanted to lock in a monetary stream of upgrades.” But if you think further, they have really been delivering fully baked features at the time they really become needed. When the iPhone app store first opened, there weren’t enough apps with functionality that would make you want to multitask. Who knew how quickly apps would catch on that people would want to copy / paste? Apple has done a great job of delivering features at a pace that allows the ecosystem to adjust, and the customers to understand how to use it.

Hopefully, on the next generation of our intranet platform, we can duplicate this success. For now, I’m calling it reductive feature design and I think that it can be viewed through the lens of technical and organizational readiness. If either of those two factors truly aren’t ready to introduce the feature, it should be removed from the version stream and placed into the backlog. Now to pitch it to the rest of the folks and see if it flies…

Building A Platform – Farmville Should not Take Down Facebook

I am joining a project at work that will revamp our intranet architecture and allow us to continue to bring innovative and cutting edge capabilities to our workforce. One of the issues that we’ve seen over the past few years had been that rich applications that have integrated with our portal have been too tightly integrated. In several cases, they have the capability to hog resources or even take a server offline due to a catastrophic fault. This is one of the areas that we want to prevent in the future and are working with our partners to articulate this desire.

This week, one of those partners was in town to talk through our needs and the analogy I came up with was that “Farmville should not take down Facebook”. That is to say the Facebook is an application platform that provides base services (demographics, content, wall updates, etc) to applications that can then use them to do interesting* things. This is similar to a corporate intranet that knows who a user is, what permissions they have, and what their demographic information is and then exposes those to applications and portlets based on their permission. In my current environment, there are some of these constituent applications that use the same resource sets as the portal platform and thus, they could negatively impact the performance of the intranet. In V.Next this should not be the case.

*Pre-emptive snarky comment: I do not consider Farmville or any of those games to be “interesting things”. In fact, I’ve never played a Facebook game. It’s merely illustrative of the type of Platform as a Service (PaaS) model that we are striving for.

Transparency in Vendor Selection


transparent screen
Originally uploaded by fromform

Part of my job involves evaluating and recommending IT solutions to business problems we face. I have a wide background in technology and do not fit the mold of a “Java guy” or “Microsoft guy”. This can be exasperating for some as they try to figure out which direction I lean and offer me sales spiels to convince me toward their product.

Even more troubling to sales reps is determining how I view solutions from IBM, Microsoft, Sun and Cisco. My previous employer was a business partner / gold reseller for those vendors and you would think that I automatically drank the kool-aid. There are people that I work with that have obvious biases towards some vendors due to past affiliations and/or friendships. If it works out for them, great. But that’s not how I roll and I do not appreciate people toeing a company line for a company they don’t work for.

I will always prefer the solution that supports the most features my business partners require, with the lowest initial and recurring costs, that has the best chance at adoption and longevity within our environment. I don’t fit any mold – I make the mold.

Automating Affinity

One of the key outcomes my project at work seeks is to assist employees in finding people and information relavant to their needs. One way that we are attempting to accomplish this is by bringing social search results onto the same page as our intranet search results. We will be displaying "Related People", "Related Communities" and "Related Bookmarks" in a right-hand panel. The relatedeness is based on the search term(s) the user entered.

This is a first step in the right direction, but in the minds of many might seem primitive. If you are a member of Facebook, you have no doubt seen the "People You Might Know" section towards the bottom right of the home screen. While cool, this is based on some simple factors – age, schools and employers seem to be the primary drivers (although I'm sure there's a little Friend-of-a-friend logic factored in as well). While on the surface this type of algorithm may seem like it fits the needs of the enteprise – it really does not. We are not trying to find "People you may know". The goal is to find people you SHOULD know in order to share knowledge, build a better product, or have a better workplace.

Is this possible? I have no doubt that it is. I also have no doubt that you need to have a base collection of artifacts, digital footprints if you will, in place to have enough evidence in place to make such a suggestion. In that regard, I believe we are approaching the problem domain correctly. Of course as with everything else I have done over the past year, I am sure that there are many more layers to this onion that will throw new wrinkles and challenges my way.

  • Recent Tweets…