As a database and application developer, I spend a lot of time analyzing clients’ requirements, defining relationships between data elements and carefully architecting a technical foundation that will bear the weight of future applications. This is crucial and interesting work, and often less time-consuming than the task of creating a human interface to collect, consume and present the data.

The software development cycle can be rather ponderous; everything has dependencies on other things, everything provides its own specific and finite capabilities, and everything demands an investment. When any one of those things fails to perform its job as part of a coordinated whole, time and money is wasted.

It’s a lot like engineering a concrete bridge; once the cement has been poured, it’s awfully expensive to change the shape of the product.

For several years that model has been changing, with a greater emphasis on creating things which are “modular” – that is, components that behave in predictable ways defined by an external set of standards. Building applications using this approach is more like assembling with Lego’s.

Enter SharePoint, which takes this model a step further by providing, behind the scenes, the ability to create and assemble its own Lego’s. In this approach, we can potentially begin and end the design process with a consideration of how a body of data should behave; less consideration is required of how individual data elements will be stored, inter-connected and presented because SharePoint knows how to do those things without our help.

The construction analogy here might be the kind of architecture that kids do on a beach, digging little channels and depressions in the sand. When the next wave arrives, the water flows in, filling the form that was created for it.

I am oversimplifying, of course, in hopes of giving an impression of how SharePoint changes the software development equation. Like earlier tools (Microsoft Access and Excel come to mind) which enabled non-technical knowledge workers to leverage technology and share their work, SharePoint brushes aside obstacles to database and web development.

It does not (and cannot reasonably be expected to) prevent poor application architecture. It does not remove the need for capable application architects or preclude custom development. It does shorten – dramatically – the path from basic application design to implementation.

It accelerates the delivery of software, but the quality of the software delivered depends, as it has always depended, upon the forethought given to its purpose. One might say that the “point” in SharePoint is indeed sharp: Whether this powerful tool is used incisively, to produce efficiency and insight, or clumsily, to impale, is up to us.