Federated Software Architecture

I've worked in large companies, and I've worked in small companies. However, a common problem I've seen in even small companies is duplicated effort. For instance, a product group will kick off a new project based on an idea, a competitive product, or market research, and a development group will go off to design and build it. Often, the design and development is done in a silo, or with limited visibility to the rest of the organization. The unfortunate result is that portions of the system being designed may already exist, but are instead redesigned and rebuilt because no one on the team knew about them.

One attempt I've witnessed to avoid this situation is the use of a global architecture. In this model, a group of architecture masters define golden designs, using a pre-defined set of technologies that no one can stray from, and they cast them down from their ivory towers for all the mindless developer citizens to follow. Obviously, in the company I witnessed this at, it didn't work, and it wasn't enjoyable to be a part of. There was no room for creativity or feedback from the individual development groups.

Instead, borrowing from the construction industry, what I propose is more of a building code for software design, complete with the need to acquire "building permits" for software construction. For companies with multiple, distributed, development groups, what I feel is also needed is a company-wide group that oversees, but does not necessarily dictate or govern, software design direction. I call this group of people the Design Support Group (DSG) .

Building Permits

A company-wide DSG would put procedures in place that would require development groups to get what is the equivalent a “building permit.”  If this is done correctly, it should also relieve project managers of a lot of the work in getting a project off the ground.

Once defined and agreed upon by all development groups, the “building permit” procedure is a process by which a project must pass its plans. This is called the DSG review procedure, and it includes details such as development languages to be used, basic architectural principals, and hardware, software, and OSs to be deployed. The DSG would also offer its suggestions as to how to design and build the product according to its expertise and experience. “Permits” would be granted so long as the project team plans to build the product according to a flexible "building code."

In the end, given that all software design passes through the DSG, people will be alerted to the possibility of duplicated effort, and it can be avoided before too much time is wasted. Additionally, new and creative solutions can be shared (instead of stifled) for the good of all future development efforts. Overall, the DSG should operate in a flexible way, offering assistance (not roadblocks) to designers and developers.

Management Relief

The DSG would also help project managers maintain project scope, and prevent feature creep. By holding periodic “building permit” meetings in the course of product development, the DSG would ensure that all procedures are being followed. It is at this point that the DSG would help to prevent non-approved features from being implemented. 

As a result, project management would then have outside, corporate, support in not being forced into over-committing to added features late in the process. This isn't meant to serve as resistance to customer needs or new feature ideas; it's simply a procedure to ensure that all new feature ideas raised during the course of development get due diligence in terms of scope, design, scheduling, and resourcing.

These additional features / requirements should be captured and funneled into their own, separate, project or release (see my Bus Stop Releases blog here). You now have an iterative process that incrementally builds a product in phases. These phases would theoretically be much smaller in size than traditional project development phases as they maintain their scope. 

Respect

Depending upon the size of your organization, the DSG can be structured such that there are satellite DSGs local to each development group or geographic region. A central DSG Project Office can be set up to unify the satellite DSGs, and to coordinate their efforts. Together, permits would be granted, and standards and procedures would be conceived and put in place. The most important aspect of this is that the local satellite DSGs should be made up of knowledgeable, experienced, and respected individuals. 

Conclusion

Is it possible to implement a company-wide DSG, with a standard architecture and procedures? I think so. As a matter of fact, I think it’s necessary for companies that maintain distributed development groups. Therefore, instead of corporate architecture and technology mandates, pre-approved system designs, and stifled technology choices, think about implementing a procedure that maintains control and avoids duplication, but also allows creativity in design and development.

What does your company do to regulate software development, and avoid duplication and rogue software systems? Write back in the comments section below and share with your fellow readers.

Happy coding (and designing)!

-EJB