Archive for the ‘Frameworks’ Category

NewImageI just posted a brief article on using Business Model Generation (BMG) as a means to articulate the rationale for how you create, deliver, and capture value. Shortly after the post, Tom Yardly posted a LindedIn reply highlighting some original work in this field. Business Model You is a one-page method for reinventing your career using concepts from BMG. Pretty exciting and I encourage you to check the site.


Please check out the original article – “Business Model Generation – A Personal Application

Read Full Post »

300px Business Model Canvas

I decided to apply the Business Model Generation (BMG) methodology, created by Alexander Osterwalder and Yves Pigneur, on myself as a means of providing other team members a personalized concrete example. This started when I was in the process of working through a business modeling exercise for a couple of my IT-related practices. A colleague, not familiar with the BMG methodology, asked if could work through an end-to-end “personal illustration.” The term “personal” provoked me to think about my career,  the work through what I do, and value that I try to create.

As most of us know, a business model describes the rationale of how an organization creates, delivers, and captures value (economic, social, or other forms of value).  Well, that is exactly what most of us do on a day-to-day basis – realize some sort of value. So, with the help of the team, I created the Dr. Jerry A. Smith V1.0 business model and here it is:

Dr Jerry A Smith bmg


This “attempt” tries to capture four of my key value propositions (strengths) – critical thinking, problem solving, creative insights, and strategy planning. As it turns out, I apply these value propositions across three very different customer segments – IT (information technology), Academia (colleagues and students), and Visual Effects and Film Industry. That was a real epiphany for me since I mostly thought I was deliverying very different values.

One of the bigger insights I have drawn from this exercise is that I am “paycheck poor.” Check out the revenue streams. See a pattern? My revenues are tied only to the income benefits from the companies or universities I work for. If I stop the work, the pay stops as well. From a business perspective, this seems a bit risky.

Anyways, I plan on doing a lot of business model evaluations over the next few week, using the BMG framework. I specifically look forward to the SWOT process as applied to model.

Please let me know what you think about the approach and results (below, email or LinkedIn).


Read Full Post »

NewImageFor those that have questions around cloud computing-baed security, taxonomies, and frameworks, please make sure you read “Security Guidance for Critical Areas of Focus in Cloud Computing, V2.1.” It contains a wealth of information beyond security issues, covering the NIST cloud computing model and OpenCrowd cloud taxonomy.




Read Full Post »

NewImage.jpgSoftware frameworks are commercially-harded sets of tools that provide developers with more flexible, reliable, and available programming capabilities. They provide necessary (capabilities without which the business model would fail) and sufficient (maximizing their incorporation into products improves business success) capabilities essential for achieving anticipated business outcomes. In commercially available frameworks, such functionality includes data access (DAO), modularization (inversion of control, dependency injection), caching (core and edge), persistence (hibernation), etc.

Without these frameworks, a disproportional amount of work (lost productivity) would be applied to non-core activities not directly oriented at fulfilling end user needs (all the software plumbing that is never seen by users). So, given the critically of frameworks in any development process, understanding what is available and comparing their relevant capabilities is an important early research for product development.

There are numerous frameworks available many aspects of the development process (web, mobile, embedded, analytics, etc.) . For those working on web based development, there are over 300 viable frameworks to choose from, spanning 10 commercially viable languages. To boot strap the research, one of the better sources is “Comparison of Web Application Frameworks,” a Wikipedia reference report.


This cross framework comparison contrasts languages, MVC/MVP, internationalization/localization, testing, data access and DB migration, security, caching, and more. It also document version history, release dates, and licensing requirements. While incomplete in many ways, the data provides a starting point for building out the business and development models needed to successfully produce today’s complex products.

Next Article: “Developing Software Frameworks – A Process.”

Read Full Post »


Several clients are asking similar questions around increasing revenue through existing products. Specifically, they are looking to leverage large sets of existing code across their enterprise products/services in order to create new solutions for existing/new markets (see sustaining vs. disruptive investment trends). They want to know whether the use of enterprise frameworks can lead to reduce time to market and reduced total cost of software ownership. As such, I am creating a series on “Frameworks” that is designed to explore the ins and outs of enterprise framework development in order to share some of the relevant findings and best practices.

Frameworks are one of the most sought after enterprise systems components, often cited as part of the financial justification for a project. However, most CEOs/CFOs discount this type of “dividends from reuse” arguments because of a history of similar failed promises. Many consider framework development for financial gains to be the Moby Dick of software industry. We are all illusively hunting for just that one, that one that promises the really big payoff, but never seem to land it when they come insight.

While there are no industry accepted definitions for “frameworks” (NIST, ACM, IEEE, etc.), most consider software framework to be an operational abstraction, allowing common code to provide generic functionality that can be overridden or specialized by the user (e.g., code, dependency injection, etc.), thus providing practical functionality specific to an end users need.


As most know, I am a big believer in dividing system characteristics into necessary (without them you fail) and sufficient (using them in large numbers you have a better chance of succeeding) characteristics. They allow one to focus on getting off THE failure path so that ANY of the success-oriented roadmaps can be taken. The good news is that new research into frameworks has identified several necessary components.

Based on some initial research, here are five key necessary elements of a successful framework:

1. Dependency Injection (DI) – As a type of inversion control, the main goal of DI is the removal of a class dependency on some code. Class dependencies are then injected into the code where it is needed.

Some leading Dependency Injection Frameworks:

— GIN (GWT INjection) – automatic dependency injection to Google Web Toolkit client-side code. GIN is built on top of Guice.

Guice – Dependency injection for GWT applications.

Spring – Java-based dependency injection

— Microsoft’s Unity DI container

— PicoContainer : A fairly small tightly focused DI container framework.

HiveMind : Another DI container framework.

XWork : A command pattern framework which effectively leverages Dependency Injection.

The application of dependency injection is one of the top framework characteristics that lead to the biggest value capture (payoff) for organizations. Being able to systematically decouple modules and subsystems helps in code maintenance, re-usability, testability, and improves code readability. DI has replaced factory patterns as best practice in decoupling functionality.


2. Extensibility – Frameworks need the ability to have additional functionality added without re-architecting the code; typically by enabling users  to selectively override or specialized behaviors through user code providing specific functionality. With this type of forward compatibility engineering,  frameworks should incorporate the design principles to ensure this—a roadmap for that portion of the road yet to be built.

There are several key measures that can be incorporated into your development built time environment in order to ensure framework are extensible:

>> Afferent Couplings (Ca) – The number of other packages that depend upon classes within the package is an indicator of the package’s responsibility.
>> Efferent Couplings (Ce) – The number of other packages that the classes in the package depend upon is an indicator of the package’s independence. 
>> Abstractness (A) – The ratio of the number of abstract classes (and interfaces) in the analyzed package to the total number of classes in the analyzed package. 
>> Lack of Cohesion (LOC) – The measure of a class to represent a single logical concept.

3. Scalability – Framework performance should scale with utilization.  As user utilization increase (sending more messages, analytics, etc.), the framework should not be the source of the performance bottlenecks. Frameworks should scale linearly up to 143% (1/.7) of anticipated user interactions.

While it is often advised to focus system design on taking advantage of hardware scalability (horizontal scalability), there is insufficient speedup potential when applied to frameworks. For example, by parallel pipelining 70% of a program, overall performance can be improved by 200% (application o Amdahl’s law). However, in most cases, frameworks can be pipelined in this way, so other in process scale measure (vertical scaling) need to be taken advantage of.

4. Default Behavior – Frameworks should do some important out of the box (concrete classes, instances, etc.) and not just be a collection of software pipes used to interconnect subsystems (e.g., abstract classes).

5. Non-modifiable Code Base – Framework users should not be allowed to directly modify its source code. Extensions should only be made through overriding, specialization, or dependency injection.

A corollary to non-modifable code is the precursor of have stable code to develop frameworks from through framework modernization programs. Most frameworks are NOT developed from scratch and are often the byproduct of existing sets of code. If the underlying code based from which a framework is derived is unstable, it is highly likely the framework will be unstable as well. One of the most important measures that can be used to determine if a set of existing code if ready for framework extraction is:


>> Cyclomatic Complexity (CC) – is used to indicate the complexity of a program. Before developing frameworks out of existing code bases, best practice CC should be less than 10. It is unadvisable to undertake any framework modernization program with CC > 50, since it is theoretically impossible to fully test the product.

Side Bar: JDepend (Java) and SciTools (multi-language) are two important tools that can be used in metric collection and analysis.


Next Article: “Software Frameworks Research – Crowd Sourced Research is a Good Place to Start.

Read Full Post »