The New Software Era
I know this is a generalization, but I think that the world of software is finally changing. For years now, we’ve heard about systems that provide enough abstraction, enough of a “toolkit” user interface so that end users could configure their own specific application functionality. Truth is, these systems were always regarded as marginal by the mainstream IT industry, for a variety of reasons: reliability, scalability, performance, universality, lack of standards etc. All valid points, of course, but none of them could detract from the fundamental demand from users to provide them with highly configurable software and get out of the way.
At the risk of over-simplifying things a little to develop my point, let’s take a look at this back-of-the-napkin comparison table between the old and new software eras:
|Old software era||New software era|
There are obvious and evident benefits to the “new era.”
The challenge, as discussed in my last post, is now that end users don’t really ‘take up arms’ and suddenly start developing their own applications. They quite like having experts at the table to guide them through the process of constructing (or configuring) a business application.
IT departments, as they are today, are poorly equipped to provide these services. The increasingly siloed approach to delivering software in the enterprise has left us with a complete lack of generalists.
- Business analysts know how to elicit business and functional requirements for a world of software where ‘anything is possible’ (no, or very few technical or UI constraints), but they don’t know how to work under the constraint of using a product as the primary vehicle of implementation
- Solution architects and developers are platform experts and have focused on developing their skills at quickly building complete applications, from scratch, by using pattern-based approaches (scaffolding, etc.), but don’t know how to work under the constraints of a product, either (as noted before, their instinct is to custom-build everything, often without being aware that it’s already there).
What ensues in an enterprise that’s committed to Microsoft SharePoint is a mix of confusion and frustration. I’ve seen any number of companies that, 2 years into the MOSS 2007 journey, still have only deployed a disorganized smorgasbord of proofs-of-concept and departmental WSS servers, realizing none of the enterprise benefits of the platform.
This is a significant challenge, both for Microsoft (who, as always, will struggle to make an argument for the 2009 enterprise agreements to customers who are not even realizing the full benefits of the previous version) and for those ‘visionary’ CIOs themselves who were SharePoint-friendly because they could see the potential of an end-user focused information management platform.
Enter the SharePoint BA
So what’s a SharePoint BA? Well, he’s a Business Analyst who works primarily with the SharePoint platform. This is someone who comes equipped with the hard and soft skills of a software business analyst and the product knowledge of an expert user/product manager. The SharePoint BA operates, at all times, under the basic assumption that everything should be implemented using SharePoint. More importantly, he works on the principle that most users’ requirements can be met with out-of-the-box SharePoint functionality. He thinks of his job as that of a guide, a marketer, a consensus builder and a hands-on implementor.
Here’s the approximate profile of a SharePoint BA:
|Skill Category||Required Skills|
This is very different from a classic BA who’s involved in specifying and designing custom applications.
From a process perspective, the SharePoint BA interfaces with the business to gather business requirements. In so doing, he continually proposes specific ways of implementing the requirements using SharePoint. Unlike typical business analysts, the SharePoint BA has an opinion about implementation and expresses it. Often, he may choose to prototype something on the fly to show the users how it could be done: “Is this what you were thinking?” – “Would this work for you?”
I iamgine SharePoint BAs will spend much of their time providing information to users about SharePoint. This could take the form of use support or training. This may end up being frustratingto SharePoint BAs – supporting end users is not every IT professional’s idea of a good time (or, for that matter, a good job). The person who’ll do best in this profile is an evangelist of sorts, a believer: SharePoint BAs should believe passionately in their madium’s ability to deliver cost-effective applications to business users.
The nature of the work, therefore, is also less transactional than a typical BA’s activities on old-style software development projects. Before, BAs used to be a specific part of the overall software development lifecycle. They elicited requirements and wrote them up at the beginning of the project. These requirements were ‘consumed’ during the rest of the project.
For SharePoint projects, the BA’s activities are more fluid and longer-term. From education to requirements, from requirements to implementation (configuration, that is) – the SharePoint BA follows projects practically end-to-end.
In my next post, I’ll try to imagine some programmatic ways to address the SharePoint skills shortage by methodically building technologies like SharePoint into college curricula and IT professional training programs.