High Performance IT Teams - Establishing your Vision

Establishing a Vision is critical for any (future) high performance team and an IT Team's vision revolves around: Platform/Technology selection, Methodology and Organizational alignment. The degree to which the team is both supported by Senior Executive leadership (in concept) and occupies a seat at the 'strategic table' will ultimately determine the leeway a team is afforded in crafting and executing their Vision.

So what is 'Vision'? I'd posit that it is the ability to strategically plan for the future needs of the business. You have a body of experience that tells you about the pitfalls of certain approaches and the successes of past deliveries. Your intuition and knowledge of the uniqueness of the organization(s) you support also factors into future plans. Your IT Vision doesn't necessarily need to directly mirror broader organizational Vision as you may take a different approach as an enabler, rather than aper, of organizational Vision. But... A company seeking to be bring new products to bear in a nascent market (residential green products/regulation? Android mobile applications? Segway commercialization?) has very different motivations than typical 'blue-chip' companies. In both types of companies, IT strategy will serve as an enabler.

So first, Platform/Technology selection. I've been part of IT architectures that were 'siloed' function models (large applications with cohesive function but overlapping (and duplicated) shared functions). The number one shared function I've seen duplicated is Customer Relationship/Record Management (Accounts, Contacts)- Your Sales Funnel Management app has a representation of the Customer as does your Order Entry/Management application and your Inventory application and your Fulfillment and your Billing. I've seen those siloed applications stitched together when this duplication causes data integrity challenges in a increasingly complex escalation as illustrated below

From
-Tightly coupled data integrations (db links from Middleware 'Agents' serving to broker transactions between these entities) to
-Less tightly coupled (arguably) point-to-point Web Services operating transactionally and synchronously to
-Event-driven, asynchronous data management through bloated middleware agents to
-SaaS models where endpoints of services are obfuscated and not managed by the IT development team

So first ask and answer the question, "What will be my software environment and what Technologies will we employ in that environment?". My first OO language was Java. I took a class at Sun way back in '02 - Java for the Visual Basic developer. I wrote a Texas Hold 'Em poker application at home in my free time and loved the modularity afforded by the language. I also liked that I could distribute my application pretty readily just by ensuring App Server tools were running on the target.

The app I supported at work was hosted on Web Logic 6 and, looking back, was a heap (excuse the pun). It made a couple of XML over HTTP calls to other service engines and suffered from poor architecture and design. Platform and Technology selection was up to each functional silo and there were more than 20 of those functions. We were inherently fractured from an architecture standpoint. We had Java applications, JSP and ASP applications, "Fat Client" apps, Business logic deep in database packages/procedures, no common logging. In short, a bevy of 'options' for the right way to consolidate. We also had a slew of folks who could write in some of the languages but not others. It was around this time, in early 2003 that I and others fell in love with the .Net platform (1.1 framework...). Some could write in VB so VB.Net was an easy transition syntactically and some could write in C# and these two languages could communicate natively when compiled down to MSIL (oh, love the Common Language Runtime...) There was a schism at hand. We all wanted to write domain-specific Web Services and a set of clients to consume them but around half wanted to write these services in ASP.Net and the other half wanted to wrap Java Web Services (god knows why...) Suffice it to say that we strove for 'fungible' resources - those who could take their skills on any service layer and apply them elsewhere. This is still something I find extremely important in hiring and I'll discuss that in more detail in a subsequent post on 'resourcing' the plan of action.

Cost is a huge factor in your consideration of a platform. Software licensing is ungodly expensive in some cases and you should look at your user community and develop a cost model to understand the relative implications of choosing one platform over another. With the new SaaS offerings (Salesforce.com, Net Suite, Azure, etc), you don't need a server infrastructure and that simplifies your cost model. But... Cost per seat licenses using hosted development platforms are, wait for it, costly.

Another consideration is your ability to deliver change to the business when they need it. Are there inherent limitations/strengths of the platform in injecting change quickly and with mitigated risk of unintended consequences? Think it through. This segues nicely into the next piece of your Vision - the intended development methodology.

You've heard of the Waterfall methodology. You've heard of Iterative Development. The (Rational) Unified Process? You've heard of Agile. Before Agile you heard of Extreme Programming (XP). You've probably not heard of Test Driven Development (TDD). What will work for your organization? I don't work in Insurance or Banking so I can't speak to the efficacy of the Waterfall methodology (intended change cascades through the development organization through various functional groups intended to better flesh out what needs to be built) there, but I will say with certainty IT DOES NOT WORK FOR TELECOM!!! When your developers do not have a sense of what the business needs (because they have to go through the sieves of Business Analysts, Project Management and System/Technical Analysts). Daily stand-ups might be good when you're doing a quick iteration but they might be burdensome when you are still in planning phases of an iteration. Use the right pieces of each methodology to effect change when your stakeholders need it.

Building on this, how is your team organized? I'm going to save most of this for the resourcing post later but think clearly about your current needs and your future needs. Do you need dedicated Support Engineers? How important is QA to your strategy? Do you value Analysts and in what capacity? Do you have an Architect? Should you? Mull it over...