Mark Bostleman

Scalability is a term often used as a performance measurement to describe an application’s range of ability to do work. It is usually applied from a systems engineering standpoint as in the number of transactions a database can process in a certain period of time.

But I would like to consider scalability at a higher level. Specifically, how application architecture scales to solve business problems. That is, the ability of existing Web-based, project-management applications to integrate the processes of many organizations on the same network, collaborating on many projects in various combinations of partnerships.

As the AEC (architecture, engineering, construction) industry takes its first steps toward doing business online, several factors are limiting adoption. Cultural acceptance and concerns regarding the fiscal stability of application vendors are at the top of most lists. Infrastructure issues such as bandwidth, uptime, and security follow close behind.

Recently, however, two other concerns have come to the forefront: data ownership and a lack of subcontractor involvement. At first glance, these two issues appear unrelated, but ultimately they are symptoms of the same problem.

They also differ from the other issues in that they point to how Internet applications are modeled and the inability of those applications to scale to the task of providing an efficient structure of information exchange within a supply chain.

Consider the architecture of the current crop of AEC project-management applications. An organization signs up for an account and creates user names and passwords for everyone with whom it works. Some of the user names are for people within the organization, while others are designated for people outside of the organization.

Everyone can log in, access information, and collaborate based on the policies set by the account-holding organization.

From a myopic, two- or three-project point of view, this model looks great, especially compared with the disconnected local-area network (LAN) applications of the last decade. But to test scalability, extrapolate this model to all or even half of all the projects in a regional supply chain, and things start to get ugly.

For example, consider a subcontractor with 10 online users that works with 15 general contractors a year. For each user in the subcontractor’s organization, there are now 15 user names and passwords required to manage this year’s projects. That’s 150 organizationwide.

Now a spreadsheet is circulated amongst the users to help resolve, for any given user and project, the correct user name and password. But when the users are away from the office, the current version of the spreadsheet is not available because they don’t have their own accounts in an online application in which to store it.

Furthermore, for the subcontractor, the number of locations and formats for companywide information has just been fragmented by a factor of 15. Worse, there is no integration or aggregation of the information among the new online locations much less among the new locations as a group and the old offline locations.

This inefficiency is not just a subcontractor’s problem. It exists for any organization that does not have its own account. Without question, and justifiably so, the general contractor is going to be the account holder if applications like these have to be used. After all, it is the general contractor’s responsibility to manage, process, and maintain communication among all organizations.

A subcontractor could get an extranet account. But the application architecture requires account holders to own and control all of the information on the projects created within the account.

How many projects are going to be managed by way of all organizations logging into, say, the drywall subcontractor’s account? Even if this were acceptable, it would only shift the source of inefficiency from one organization to another.

The problem is that these applications assume that several organizations revolve around one organization that contains a project. The reality is, organizations revolve around projects not other organizations. More importantly, projects are not contained by organizations.

So why would an Internet application be modeled this way? Because the applications in use today are the same applications that were in use 10 years ago and moved, as is, to the Internet. By simply porting the old architecture to the new platform, huge benefits were gained. Now everyone can get to the application from anywhere at anytime.

But they were not designed for an environment like the Internet where every organization is participating. Instead, their design is a carryover from an environment in which each organization was isolated in the shell of a LAN.

As a result, they revolve around a single organization that contains projects.

Today’s AEC extranets are like biplanes in orbit. They move faster than they did in their native environment, but they have no chance of navigating efficiently.

The prospect of seamless interoperability among all applications might alleviate some of the symptoms. But to reap the full benefits of a network common to all organizations, project-management applications must be built to scale to the needs of a complex, project-centric AEC industry.

About the Author:
Mark Bostleman is president of ProjectVillage, Holland, Ohio. He can be reached at mbostleman@projectvillage.com