Business Capability Model

Current group I am working in is responsible for functional architecture. In spite of the fact that I don’t have any practical experience, I have been asked to help define a practice in Business Capability Modeling.

I think the reason for that is that I have some practical insight into the requirements that functional architecture or functional systems design places on a business capability model.

The most core principle of functional architecture involves the semantics of units of work. In fact business capability modeling is about defining the semantics of units of work – so there is my connection point.Continue Reading

Product Centered Worldview

Agile thinkers focus on the product – and how we are intentionally adding value to a “software asset” and potentially how we manage our “portfolio” of software assets. Phase-Gated Delivery (some people call it waterfall) patterns allow us to “optimize” the work against the constraints – but do not allow us to optimize the value delivery in time. In fact, they push ALL the value delivery to the very end of the cycle. But in theory, because we can optimize the projects by minimizing the schedule and cost against a constant value output – the value can be had for less investment. Problems arise when – the actual value is realized over time (meaning the sooner the customer has access to a software capability, the sooner his actual costs go down or his profits go up).Continue Reading

The Slide

Did ya ever work on a project that seemed like the schedule was too aggressive? Where the team had to constantly fight to stay on schedule, and to keep moving forward? Where things maybe got behind and we piled more resources on to catch up? Where things felt bad, but we kept on fighting until…


…it was too late. Like in baseball, when the only way get on base is to slide in? Like in football, when you just need that one more yard, and you then turn it over?

The thing is, software development isn’t a sport. We don’t have an opposing team. We don’t have a team owner or coach. Software development is a business activity. It is an activity of manufacturing, of logistics, of research and development and of analysis.

The enemy is risk. In order to defeat risk, we have to understand where risk comes from, and we have to understand how to retire it. Risk is tricky because it costs you little (or nothing) to carry it, but much to quantify, even more to retire it, and potentially even more when it is realized.Continue Reading

Emergent Vs. Inverted Thinking

In agile communities developers, project managers, testers, there is a phobia or paranoia about big ANYTHING up front – that is we should not spend more energy up front than is absolutely needed to get the committed stories/features done in the next iteration.

The concept that we use is emergent thinking. Requirements emerge as we bootstrap our thinking by delivering early features. Design emerges, as we build features that have similar needs, and we refactor towards opportunities for generalization or re-use. Plans emerge as we estimate and sequence the stories in the backlog.

So what happens when the requirements don’t emerge. When the design doesn’t emerge. When it feels like we are just skating on the surface, because there is too much fear of bigger change, or spending energy building anything now because it will all change in 3 weeks. When the product owner is unable to sequence the backlog because there are unmade business strategy decisions that are inhibiting the emergence of plans, requirements, and designs.

I use inverted thinking. It is the opposite of big anything up front- I envision a result (it doesn’t have to be the right result) and I build a plan to acheive that result. I work backwards from a conclusion, as if my decisions were made. I propose a design (as thin as possible) that I think will support the envisioned result. I build a plan (as thin as possible) and propose needed skills and resources.

I pretend I know everything, and when I need an answer, I make one up. But every answer I make up, I list as a decision – because that is the schedule I want. What decisions need answers in what sequence, by what date, and what deliverables are dependent.

Then I dare every stakeholder to tell me why my proposal (that I just completely fabricated out of BS) is wrong. If you can’t give me a good reason not to do this, we are going to move forward in this direction.

When the fear of making a wrong decision is inhibiting the emergence of requirements, plans and designs – Invert the thinking from “What should we do?” to “Why shouldn’t we do this?”…

…and watch decisions emerge.

Design Assumptions

Pragmatism – design assumptions are about pragmatism. Pragmatism is the easiest path to good enough. If I already have tools available that will allow me to do the job "good enough", why would I go buy and learn new tools? If I already have a team that supports 5 applications written in Java, why would I build a new application in C# or Ruby? If I have an application written in C# using HTML/AJAX/Jquery/CSS to do user experience, why would I build my next screen using Silverlight? Why would I go out of my way to add cost, time, and risk to a software project? Simple answer, I wouldn't.

Design assumptions, are about documenting the "status quo". They are typically written before I have thoroughly understood requirements, in fact, they are not about the requirements. They are about everything but the requirements. They are statements that require a compelling reason to change. That reason should be related to I can't meet the requirements unless I undo this assumption.

Design assumptions can also be used to document constraints that come from the organization or the project. For example, the normal time frame for establishing a new test environment is 30 business days. The desired time frame for delivery of these capabilities to production is 3 months. The project budget is $120,000. Only approved open source software can be incorporated into application build.

These assumptions and constraints have the following properties:

  • Known apart from the software requirements.
  • Express inertia, obstacles, or guardrails that the project must contend with.
  • Cannot arbitrarily be removed, changed, or overturned.

Documenting design assumptions is important, because they communicate to the team (especially when bringing new team members on board) a starting point for design. We are doing it this way, unless there is a compelling reason to change. We are constrained by these factors that can only be changed for good reason. They also communicate to your customer (who may be reviewing your design) some things that they have the power to change if it makes a difference.

When we make design decisions to comply with time or budget constraints, it may mean a reduction in quality or sustainability. When organizational constraints make it cost more, or take longer to produce the same solution, we can decide whether the constraints are reasonable.

Finally, in a project oriented culture, assumptions are a convenient way to "roll" design decisions forward release by release. If your organization maintains documentation by project, rather than by software product, it can be easy for core design decisions to get lost after a few releases, especially if the development team has substantial turnover. After a a short period of time, nobody remembers how or why we decided to organize things, and new features can be built contrary to the original design principles that were followed, only because the people who built them didn't know there were principles (or couldn't see them clearly in the code).

A Template That Inspires Innovation

After adopting a new design process philosophy, and implementing a trial project using it, a design anti-pattern has presented itself.

Document Driven Design – this anti-pattern is the practice of allowing whatever document template is mandated, drive the actual process or practice of design.

It is common in the enterprise space, especially post Sarbanes-Oxley where such documentation is as essential for passing regulatory audits as it is for constructing application systems. Sometimes enterprise management get confused as to which is the primary objective. While I haven't read the federal register to determine what actually is required, many organizations have followed the consulting firm model, and developed a documentation framework for software projects that is mandatory.

I would expect that organizations that are towards the higher end of the capability maturity model use templates that are reflective of their already mature process, but organizations that are more steeped in chaos may be tempted to produce document templates that are an amalgamation of several different processes, thinking that those responsible for authoring those documents will know how to complete them. I have seen that this is not the case, and it can cause the aforementioned anti-pattern, that is reflected in the following statement: Design is complete, when the document is done.

As I said, I realized this after trialing a new design philosophy. New philosophy has 5 steps – initiate, decide, articulate, analyze, review. Articulate is the step where the the first draft of formal design documentation is created. The team had done fairly well, following the requirements of the philosophy until this point, and when they got there, we tripped over the template. Boom! Instead of figuring out what needed to be articulated, we attempted to cram all of the decisions we had made into the existing template, and became confused and the result was frustration. We got to the review step, and questions and accusations were flying. I had a great deal if trouble figuring out what went wrong.

What was the problem? Template thinking trumps philosophy! Why? I suppose that this is an instance of transposition of the familiar.

Now I realize that I have a challenge – that to support our new design philosophy, I need to construct an "articulation template" that can inspire innovation and help the team with the remaining steps of analysis ( which in my philosophy is impact analysis) and review.