Tag Archives: bespoke software

Frameworks for Bespoke Software in the Context of Enterprise Architecture

Posted on by
Reply

In my previous post I spoke about the cost and complexities of creating a framework for bespoke software. In this post I want to look at how one can evaluate the appropriateness of a framework in the context of enterprise architecture. Such an evaluation needs to take into consideration the operating model of the business as well as the current stage of architecture maturity of the enterprise architecture of the organization.
Detailed information regarding operating models and architecture maturity can be found in [1] (with some information available at [2]). Here I will just provide sufficient information on these to support this discussion.

Operating Model

An operating model defines the necessary level of business process standardization and data integration required to run the business effectively.  Business processes are standardized when they are the same across organizational units. The level of data integration required is typically driven by the proportion of customers shared across organizational units. Based on the required levels of business process standardization and data integration, different general types of operating models can be defined:

  • Diversification – Different organizational units have different business processes and different customers.
  • Coordination – Different organizational units share a large number of customers.
  • Replication – Different organizational units have a set of shared business processes.
  • Unification – A set of business processes and customers are shared across organizational units.

Organizational units in this context can refer to any unit within an organization, i.e. business unit, department, branch etc. Different operating models can be defined for different levels of organizational units.

Architecture Maturity

Even though the business may be characterized by a specific operating model, this operating model may not be well expressed in the current enterprise architecture of the organization.  The different stages of architectural maturity give an indication of how well the operating model is realized within the software systems of the organization. The stages of architectural maturity are defined as follows:

  1. Business Silos – The key business driver at this stage is to encourage innovation with organizational units largely operating independently. Key characteristics of this stage is a proliferation of technologies and solutions
  2. Standardized Technology – Proliferation of different technology platforms during the Business Silos stage increases operating costs. The Technology Standardization stage aims to reduce operating cost by reducing the number of technology platforms.
  3. Optimized Core – Business processes and data are standardized throughout the organization in accordance with the operating model of the organization.
  4. Business Modularity – Reusable system modules are leveraged to enable business agility.

Evaluation

Martin Fowler in his Analysis Patterns book states [3]:

To accomplish component reuse for information systems, a common framework must be established. An effective framework must not be too complex or too bulky. It should be widely applicable across a large domain and be based on an effective conceptual model of that domain. Developing such frameworks is difficult, both technically and politically.

In order for a framework to be widely applicable, it needs to be closely aligned with the operating model of the organization. Creating a framework for optimizing business processes in an organization with a Coordination operating model is probably not a smart move.  In a similar vein creating a framework in an organization with a Diversification model may not provide adequate return on investment (ROI).
The architectural maturity stage of the organization has to be able to support building of a framework:

  • Building a framework during the Business Silos stage will politically be a difficult sell due to a clash of priorities. In order to be successful at building a framework, the stability and integrity of the framework has to be preserved at all cost. This may mean that the implementation of new features needs to be delayed to maintain framework stability and integrity [4]. This approach is clearly at odds with the typical time-to-market pressures of the Business Silos stage.
  • It may be tempting to create a framework at the Standardized Technology stage, but lack of standardized data access and business processes will result in limited opportunities for reuse. Proponents may argue that a framework may be the means through which an organization progresses from the Standardized Technology stage to the Optimized Core stage. Still, in order to be successful, standardization needs to precede framework creation.

Summary

In closing, here are my general rules of thumb regarding framework development:

  • Consider creating a framework only for organizations which has a Coordination, Replication or Unification operating model.
  • For a Coordination operating model focus framework design at optimizing data access.
  • For a Replication operating model focus framework design at optimizing business processes.
  • For a Unification operating model aim framework design at optimizing data access and business processes.
  • Create a framework only when the organization has reached the Optimized Core or Business Modularity architectural maturity stage.

If you consider deviating from these guidelines, it will be in your best interest to have a watertight; well documented business case, signed-off by the relevant stakeholders.

Bibliography

[1]     J. W. Ross, P. Weill and D. C. Robertson, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, Harvard Business School Press, 2006. http://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execution/dp/1591398398
[2]     “Center for Information Systems Research,” MIT Sloan Management, April 2013. [Online]. Available: http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/.
[3]     M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997. http://www.amazon.com/Analysis-Patterns-Reusable-Object-Models/dp/0201895420
[4]     J. Tulach, Practical API Design: Confessions of a Java Framework Architect, Apress, 2008. http://www.amazon.com/Practical-API-Design-Confessions-Framework/dp/1430243171

The Problem of Building a Framework for Bespoke Software

Posted on by
1

The business rules which form the basis of the unique product offerings of corporates are typically embedded in bespoke systems. Gartner, in their 2013 IT Cost Optimization (ITCO) webinar [1], states that the biggest ITCO opportunity is found in reducing the per function point application development costs. To this end corporates may look towards writing their own frameworks in order to achieve ITCO targets. Although building a framework may be a viable option, it is certainly not a guarantee for success.

Benefits to be Reaped from a Framework

Let us first look at the benefits companies hope to reap from creating their own frameworks:

  • Developer productivity – Reuse is an often cited benefit of frameworks [2] [3]. Instead of different business units creating their own but slightly different business capabilities, business units can leverage off the common business capabilities provided by the framework.
  • Shorter time-to-market – With readily available common business capabilities, the assumption is that business units can focus on only developing the delta of differentiating business capabilities unique to their particular business unit. The ability to focus on the differentiating business capabilities of the business unit; enables business units to push new products into the market much faster. This in turn results in prompt return on investment (ROI).
  • Reduced maintenance costs – Since common business capabilities are only implemented in one place, it is developed and tested once. When the business rules change, changes to the relevant business capabilities can be made in one place.

Complexities of Designing a Framework

If there are so many benefits to having a framework, why are all corporates not creating one? Frameworks are orders of magnitude more complex to design due to the higher level of reuse, the need for constant evolution and backward compatibility [4] [5].

  • High level of reuse – In software development reuse is often considered a virtue [6] [7] [8] [9]. When stable and robust artefacts are reused, this is certainly true. However, reuse can become a vice when the artefact in question is in frequent flux and/or brittle.
  • Constant evolution – Requirements are seldom stable. As requirements change, the framework will have to evolve gracefully.
  • Backward compatibility – If clients are forced to make major changes to their existing code every time a new version of the framework is released, developer productivity is hampered rather than accelerated. Backward compatibility is not merely achieved by keeping API signatures consistent: It also wreaks havoc in instances where the underlying behaviour of the framework changes between versions.

Impact of Getting it Wrong

Multiple incompatible variants of a framework are a sure sign of a framework failing. Please note: I am not talking of legitimate versions here which forms part of a roadmap. Rather, I am talking of accidental variants of the framework that come into existence due to attempts at addressing flaws in framework.  These variants may come about for a number of reasons.

  • Use cases of the framework may not be clear resulting in teams inadvertently using the framework incorrectly. That is the framework is accidentally used in a non-backward compatible way.
  • Brittleness of the framework may force teams to independently hack the framework into a vaguely working state resulting in multiple incompatible variants of the framework.
  • The framework may not have been designed with backward compatibility in mind. The effect is that the effort to upgrade to a later version of the framework becoming an obstacle in itself.

Needless to say when multiple variants of a framework exist, it destroys all intended benefits:

  • Maintenance costs will increase due to the inherent complexities associated with frameworks. With each variant of the framework evolving independently, maintenance costs are increased further.
  • Developer productivity will be decreased due to increased complexity which will cause an increase in analysis time. These additional efforts will increase the time-to-market which hurts ROI.

Guidelines for Making a Framework work for Bespoke Software

Does this mean frameworks are a bad idea for bespoke software? Certainly not! Here are some guidelines for making a framework work for bespoke software development:

  • Design stepwise – Do not attempt to provide the solution to all problems in one go. Particular good advice from both [4] and [5] is that a new feature should rather be delayed or not added at all when adding it will cause the integrity of the framework to deteriorate
  • Build slowly – You are going to make mistakes, especially if you have a team with limited experience in building frameworks. Remember, once you have added features into the framework, removing them can be extremely difficult to almost impossible. Building the framework slowly gives the team the opportunity to learn without making too many commitments to their users that they cannot honor in the long run.
  • Manage business expectation – An appropriate framework has the ability to reduce time-to-market substantially once it has reached a critical mass of functionality. A key point is that while it is in the process of being built, it slows down time-to-market significantly due to the inherent complexities in building a framework. Business expectation has to be managed accordingly.

Conclusion

Frameworks certainly have the ability to decrease the per function point application development costs, but the cost of naively embarking on a framework journey should not be under estimated.

Works Cited

[1] K. Potter, “2013 IT Cost Optimization: Strategy, Best Practices and Risks,” 5 December 2012. [Online]. Available: http://my.gartner.com/portal/server.pt?open=512&objID=202&mode=2&PageID=5553&ref=webinar-rss&resId=2232818&srcId=1-2973089105&prm=tpc-itco. [Accessed 15 Febuary 2013].
[2] M. Fayad and D. C. Schmidt, “Object-Oriented Application Frameworks,” vol. 40, no. 10, 1997.
[3] D. C. Schmidt, “Applying Design Patterns and Frameworks to Develop Object-Oriented Communication Software,” in Handbook of Programming Volume I, MacMillan Computer Publishing, 1997.
[4] J. Tulach, Practical API Design: Confessions of a Java Framework Architect, Apress, 2008.
[5] K. Cwalina and B. Abrams, Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, Addison-Wesley, 2009.
[6] M. Fowler, K. Beck, J. Brant, W. Opdyke and D. Roberts, Refactoring: Improving the Design of Existing Code, Addison Wesley, 1999.
[7] S. McConnell, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, 2004.
[8] R. C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall, 2009.
[9] K. Beck, Implementation Patterns, Addison-Wesley, 2008.
[10] J. W. Ross, P. Weill and D. C. Robertson, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, Harvard Business School Press, 2006.
[11] M. Kanat-Alexander, Code Simplicity, O’Reilly®, 2012.