Supercharge Your Application Development Open Source Strategy with an Architecture-centric Approach

The Application Developer's Concerns

With enhanced tools and know-how come higher expectations. Software developers today face ever-increasing pressure while developing their applications. The need for more functionality, shorter delivery cycles and lower cost structures makes it seemingly impossible to deliver in a manner that makes all interested parties happy.  This pressure comes from both external and internal sources and is particularly true for those building and selling software-based products.

Externally, market innovation and evolution require applications {sidebar id=1} to stay on par with benchmarks and standards. Customers endlessly request differentiating and complex requirements and competitors enjoy pointing out weak spots or lack of functionality.

Internally, the pressure to improve time-to-market, content and lower costs may stem from a more critical need, such as business, product line or application survival. Often inefficiencies within an application developer's environment are partially to blame for project delays and cost overruns. Redundant or missed tasks within project execution may be rampant due to a lack of reuse, communication, process and/or standardization.

Open Source To The Rescue

Wherever the source of the pressure and the associated pain points experienced by developers, leveraging open source technologies has had a significant impact on both the development and runtime environments of software applications. This impact is often beneficial and tends to provide a qualitative means to deliver applications with expected functionality within timeframes acceptable to interested stakeholders.  When given the option to choose between open source widget v1.0 or its commercial v1.0 equivalent, early released versions of open source software tend to be better tested and market-proven than their commercial counterparts. But, of course, there are trade-offs.

Benefits Of Integrating Open Source Software

The benefits of open source software are well known and clearly identifiable. Within the context of application development, open source software can encourage software re-use, improve quality and security, protect from vendor lock-in and even allow greater flexibility in customization. From a short term perspective, open source software or services can be utilized easily for specific projects when a particular pressure or pain point is taking its toll. Typically, this narrow focus will allow the team to recognize some level of positive ROI immediately, especially if longer term goals or objectives for an application are not included in the project justification or funding criteria. A more careful consideration of an open source strategy must take place to address the challenges required to sustain the benefits for the long term. 

Challenges With Integrating Open Source Software

In the fast-paced world of application development, decisions to use open source technology are often rushed. The benefits alone are used as the criteria to address immediate application needs. Consequently, the challenges that accompany open source strategy decisions are often misunderstood or ignored.  Failing to consider the open source challenges alongside the benefits can significantly decrease the longevity and applicability of an application and increase project risk factors.

All software projects have challenges. Open source projects are no different. Some of the more common challenges that accompany open source technology development include:

• Community-based support structure. When questions, problems or ideas arise, the mechanisms for expressing these thoughts are different from those in the more familiar commercialized software environments. For open source software, support interaction is typically handled through Web forums, wikis and other Website means in a democratic fashion. The level of community involvement varies depending on the topic or technology. Support discussions generally focus on the newer releases or betas. Teams must understand mitigation plans and/or exit strategies ahead of time when an open source technology takes a turn in a different direction, becomes unstable/stale, or insufficient support is provided.
• Sporadic release cycles. Open source projects are notoriously unpredictable in their release cadence. Release cycles can be very long or very short depending on the maturity of the technology or volatility of the market. Teams that use open source artifacts must structure their applications in such a way to absorb this variability without significantly impacting their user base.
• Contribution management. Whether receiving or supplying contributions for an open source project, it is important to consider how these contributions are managed within the developer's application domain, such as which contributions are added to the application and when. The luxury of the having access to open source code can be a double-edged sword and assumes a certain amount of responsibility and accountability. On one side, there is the ability to change the open source code. On the other side, there is the ability to change the open source code. Think about it.
• Dynamic roadmaps. Open source projects tend to have very fluid roadmaps. The features, enhancements and fixes targeted for a particular release are rarely committed to well beforehand. Some of the more mature projects are getting better at this. It is also worth monitoring the roadmap for any change in direction or vision. Developers must find a way to loosely couple their application's dependencies with open source software.
• New Technologies.The technologies and standards used in open source software may not align properly with the skill sets and domain knowledge of the development team. Even if the open source technology is proven and scalable, if it is not well understood internally it can have a detrimental effect on the developer's efforts going forward.
• Extra-functional requirements. Teams often overlook the non-tangible or extra-functional requirements and constraints that open source software place on the application or its environment to fully leverage the new capabilities. Performance, availability, scalability, testability, recovery, network utilization, etc. affect how the functional requirements (e.g., add, edit, calculate, get, show, etc.) behave. Evaluating upfront the constraints and boundaries placed on an application due to certain open source ingredients will save the developer from unexpected surprises when implementation or release phases are executed.

Failing to fully account for these challenges will certainly affect a project's success. Choosing an open source component as a quick-fix solution could eventually turn the developer's efforts into a continuous state of refactoring as new open source releases and enhancements become available. At its worse, this scenario could lead to the long term effect of the developer spending more time changing his application for the purposes of open source upkeep rather than the more revenue-generating efforts of crafting new and innovative features and functionality. The good news is that the challenges of open source can be navigated successfully.

Using Architecture To Address Open Source Challenges

An architecture-centric approach to an open source strategy will address these challenges. An architecture-centric approach means identifying the architectural style, supporting framework and set of best practices that will govern how open source technology should be used within the context of both the application's development and runtime environments.

An architecture-centric approach allows a developer (business or product line) to sustain the benefits of open source software for the long haul while enabling the separation of the application developer's concerns (i.e., business functionality) from the efforts required to select, integrate and leverage open source ingredients.

Architectural Style

An architectural style is the set of guiding principles, rules and structure that, when properly followed, enables application longevity beyond any specific open or closed source technology lifespan. An evolutionary list of architectural styles includes structured programming, object-oriented, distributed object-oriented, enterprise component and service-oriented styles. As application complexity grows over time, application architecture becomes more important. A carefully selected architectural style can help address the complexities of interoperability, distribution, compatibility or adaptability. Together, component-based and service-oriented styles are addressing the more complex and enterprise-wide concerns for application developers today.

When a developer evaluates and selects open source ingredients for an application, aligning architectural style between the application and its open source choices is important. This allows for better absorption, integration and functional growth, thus creating a more cohesive and easier to maintain application. As the complexities of functional and extra-functional requirements increase, so does the value of using and building software whose styles are more component- or service-oriented.

Architectural Framework

A well defined architectural framework supports the selected architectural style. An architectural framework can address the critical concerns for constructing applications that must exist within an enterprise-wide context. A good framework enables the selection, integration and deployment of best-of-breed ingredient technology (open source, commercial, etc.) required to meet changing business concerns without significantly impacting functional development.

Therefore, implementing an architectural framework allows the developer to retain architectural control of his application by remaining technology independent, address critical and strategic concerns, and free to swap open source ingredient technology ‘A' with open source technology ‘B' when needed without major rework or refactoring.

This may sound a little preachy, but the fact is that many application developers do not generally take the time or are ignorant on how to protect themselves from open source train wrecks. Small- to medium-sized application development teams tend to lock-in tightly with open source solutions, only to find out too late they are in trouble when their open source selection goes stale or inadequate support is realized.  An architecture framework is extremely important to be able to change ingredient(s) with little or no effect to the rest of the application. This is critical for enterprise-wide applications (distributed, highly available, redundant) - but may be outside of the realm of most application developers' focus.

Best Practices

Many open source communities promote best practices in their software, making it easy for developers to absorb their software into an application and into a development environment. Open source projects typically demonstrate:

• Agile-centric development. Aids integration of open source projects' sporadic release cycles into the application environment through continuous build processes. Captures issues early and often with a test driven harness
• Component-based development. Makes it easier to control the complexities of component integration (open source, internal and/or commercial) during development and deployment. Promotes autonomy and cost effectiveness.
• Single purpose discipline. Seeks open source technology that is built to address a specific requirement. Avoids stretching the boundaries of open source software to fulfill a requirement it is not fully capable to perform.
• Separation of concerns. Applies appropriate architectural style and framework for the application and its runtime and development environments to protect the functional development activity from the volatility of ingredient technology change - a major contributor being open source software.

Additional Benefits 

By applying an architecture-centric approach a developer's open source strategy can successfully address the challenges of open source software.  The benefits can also be extended in a sustaining and repeatable manner by equipping the application's development and runtime environments with an architecture that promotes longevity and technology independence, whenever open source projects come available or fade away. An architecture-centric approach ultimately supercharges an application making it adaptive to a myriad of demands, able to deliver when needed at a price point that the business can afford.  

An architecture style and supporting framework can enable the integration of different frameworks, styles, and standards found in many proven open source solutions today as well as support iterative and continuous development. Enterprises embracing architecture-centric agility can greatly increase long term benefits of the open source strategy without jeopardizing the core business value and mission along the way.
 

About the Author Jeff Hodson has over 20 years of experience in delivering market proven real-time enterprise applications for the financial and telecommunications industries.  He is currently serving as a Director at Herzum Software (http://www.herzumsoftware.com/) leading its Agile Outsourcing and Project practices.