When to Incorporate Software Product in the Design and Delivery of an Information System
Information systems have become the drivers behind the branches and departments that constitute the US Federal Government. Architecting, developing, implementing, and maintaining these systems translates into big business for the system integration (SI) community and for good reason – successfully delivering this type of work is no simple undertaking.
In our experience, it’s not uncommon for an SI company to claim they can build what the software industry readily offers out-of-the-box. While we don’t want to discredit these statements, our goal with this blog post is to share our thoughts on when to consider including software product into the design and delivery of an information system. We’ll start by outlining some definitions.
A system is defined as “a set of interrelated components working together toward a common goal*.” Information systems are a very particular type of system that NIST more narrowly defines as: “A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.”
Software products, on the other hand, are the very components or information resources referenced in the above definitions. Note not all information system components are products but most enterprise-grade software products are components.
While it is undoubtedly much easier to distinguish between system and product in the physical world (think aerospace or nautical systems), there is often a blurred line between the two in the technology space. We believe this blur is a result of some combination of the following phenomenon:
Instances where a single software product comprises the bulk of its parent system. If you’ve ever worked with a system that fits this mold, imagine removing the core product – does anything usable remain? If not, it’s easy to understand why product and system become conceptually interchangeable.
Software products that are so complex they emulate the very characteristics of the larger systems they are a part of. When the ‘hoods’ of these products are opened, they present like a system in their own right. For this reason, a term called ‘fractal view’ has been used to describe the recursive nature of the technology stack. A non-technical analogy to depict this is the classic Russian doll.
The perception that because software products are merely lines of code, an experienced software developer should be able to replicate those lines of code in-house, making purchase of an external product unnecessary.
Item #3 is probably the biggest barrier preventing software product from entering an information system and understandably so – why add signing a software licensing agreement to the mix if the government can leverage their trusted, onsite technical resources as an alternative means to achieve the same desired end-state? Before reaching this conclusion, however, below are some suggested questions to consider:
Does the product encapsulate expert, niche knowledge that goes beyond the scope of what a traditional software developer is trained in? For example, we’ve worked with natural language processing (NLP) software companies that have computational linguists and traditional linguists on staff – this expertise is essential for building successful NLP software but it’s not expertise that most traditional software engineers have.
Is the problem that the product is trying to solve unique to just my organization? If yes, a product purchase might be overkill. If no, a product purchase most likely makes a lot of sense – no need to reinvent the wheel if a 3rd-party software vendor has readily invented it for you.
Does the software product roadmap align with my organization’s strategic goals and vision? Note the rate of innovation often present in these roadmaps is something that information systems could (and should) be taking full advantage of. Further, the software industry’s pervasive adoption of the agile software development methodology enables them to incorporate individual feature requests fairly rapidly.
Note the questions presented above are a mere sampling of things to consider when deciding whether to incorporate software products in overarching information systems. There are vetted and proven techniques from the systems engineering discipline that can be used to help formalize such decisions, including undertaking a trade study or analysis of alternatives (AoA). When all is said and done, we believe these techniques are key to developing balanced information systems that have the appropriate blend of onsite technical resources and outside software products from the technology sector.
Like anywhere else in life, balance is key.
* Kossiakoff, A. (2011) Systems Engineering Principles and Practice, Second Edition. Wiley.
