As I recall it, the writer said that the US Marines had a “70% rule” as part of their military doctrine. In short, I remember the rule as “If you have 70% of the intelligence you need, and have 70% of your forces in place, and have 70% of your plan complete, you should begin execution of your advance.”

This concept has stuck with me, and I have pondered it and applied it in many situations over the years, but especially in software development.

I would phrase the software development version as:

“When you understand 70% of the long-term market need, you understand 70% of the design of what would satisfy that market need and you have 70% of your team assembled, you are ready to proceed with full development.“

On software development teams, we are constantly besieged with the angst, and the nagging doubt, of questions like:

“Why don’t you have more done?”

“Should we wait until requirements are complete?”

“Will the developers be just sitting on their hands if we ramp up now?”

“Do we even have a clue how long this project will take?”

“Will the product owner change his mind and tell us to build something different next week?”

“Do we really understand the market?”

How do we resolve these questions? How completely must we resolve them?

I think that being able to acknowledge that the required knowledge or readiness of the group is incomplete, but that we can start full development when we reach a certain threshold which is less than the unattainable 100%, helps the group to become comfortable with the path that they’re on. Success of this stage of the project may now seem more achievable.

I have found the 70% rule to be a great test of the completeness of your market research, requirements, architecture, top-level design and team formation, and it has worked well for me over the last four years. I find that I have probably been applying a rule like this for the last 20 years that I’ve been leading projects, but had never articulated it as a rule.

Of course, it’s easy to argue that you can’t know if you’re 70% done until you know what 100% looks like.  This is not a rule that lends itself to precise measurement, but rather must be handled with judgment based on experience, and intuition. If there is a good conversation going on between the participants, you can tell when things settle down and the rate of change drops way off.

I have often heard the 80/20 rule invoked in various forms – “80% of the features require 20% of the effort, the last 20% of the features require 80% of the effort”.  I think this is a closely related topic, but speaks more to the search fro perfection among craftsman, in tension with the pragmatic need to get a product out.

I relate this to the ongoing comparisons of planned SDLCs to agile SDLCs. The agile process community asserts that planned processes ( so-called “waterfall” processes ) are trying for 100% of the requirements and 100% of the design before they write code. I find the reality to be somewhat less extreme, but there is still that push for completeness and change control, particularly with requirements. The attempt to reach the unreachable 100% results in the classic “analysis paralysis” problem. There are iterative approaches, like the Unified Process, which when properly applied can mitigate this problem.

I hear the planned process community asserting that the agile processes start with, oh, maybe a 10% understanding of the requirements, and the team must explore the rest of the requirements and work their way out of dead-ends and sub-optimal choices as the project progresses. The reality here is also somewhat less extreme, but in my experience I’ve felt the group started with a 30-40% understanding of the requirements, based on the work required to green-light the project, and the knowledge gained by the product owner before the developers joined the team.  I think for small groups, IT projects, and contract projects this might be sufficient, and have seen it work well. I’ve seen it work disastrously for product companies where re-factoring a product post-release is not really an option, where there is a 5+ year road-map to follow, and especially where the domain/data model is critically important.

So I have found a common ground between this military doctrine, my experience with software architecture/management/development, and my experiences on planned and agile projects. I think that the 70% rule is a fairly pragmatic threshold to use to move from the “what is it” to the “let’s build it!” phase of a project. Or perhaps this rule is also saying that the first 70% of the design is planned, and the final 30% of the design is agile. No plan survives the start of the campaign.

I prefer the term Software Component Architecture (SCA), which implies the fundamental properties of services used in software products (as distinct from IT projects and the selling of al la carte services). I think these properties are:

1. The units of deployment are the services, the client applications and the data stores.
2. An SCA product is composed of services, and applications are composed from those services.
3. An SCA product may expose services directly, but is not intended to provide only services.
4. An SCA product generally will include authentication, authorization, session management, services, data stores, and management tools.

Note that the term Service Component Architecture has also been used some years ago to describe a deployment model for services built on application servers, which is now under the management of OASIS.

I’m currently working on a project to create a web services based product.  Broadly speaking, the product (like many today) will be composed of services which are composed into one or more web-based applications. For competitive reasons, I cannot go into details of the product.

I take a liberal use of the term “services” here. We’ll be using SOAP based web services using WCF and .NET 3.5, and possibly using REST and JSON for Ajax services. We may also have some legacy services which use message queuing or TCP/IP messaging.

However, I would like to explore some of the differences between the typical SOA project, and the SCA Product.

Typically, SOA is positioned as a new model for organizing a business, where the business is first divided into autonomous services (like “Inventory”,  “Create Order” or “Track Shipment”). TYpically we’re not talking about a re-creating these business units, but simply thinking about them in a new way.

SOA also is associated with web services technologies that allow you to put a facade on the existing business functionality, and use various tools to call the services and create web based applications to perform a business workflow. There are certain key technologies, such as an online service catalog, that solves problems such as the location of the services.

There are a number of technical and organizational challenges to SOA projects, such as inconsistent types, data models, SLAs, and getting business units to invest in supporting a service that they are not directly selling.

The SCA Product does not generally share these problems, and introduces a completely new set of issues.

• In SCA Products, you have to be considered with scaling the business, profit margin, support cost, and competitive features.

• In SOA, you’re integrating one set of systems. In an SCA Product, you are likely integrating to a new set of services or existing systems for each customer.

• In SCA, the services are exactly where you configured them to be. They are generally within your control.

• In a green-field SCA Product, you control the domain model for all entities (whether you choose to exercise that control or not), and you control all the service contracts.

• Business drivers include time-to-market, granularity of versioning, and the ability to license individual services.

• SCA Products often require performance that is 10 to 100 times higher than SOA projects.

• You control both the client application and the services.

• You have to provide support for the SCA Product.

I think that the services model, composed applications and domain-driven development will create great advances in product design. I have not seen much written on product development back in the object-oriented and the component. I hope that we’ll see more written about product development in the service era. I’ll try to blog the interesting aspects of product development as I encounter them.

I’ve been involved with software for about 25 years, and am a veteran of two successful start-ups and consulted with a handful of other start-ups. I guess I bring value as a bridge between product management and the software developers. In my earlier days I was a hard-core C++ developer on HP-UX and Windows; now I work with .NET and C# on Windows Server 2008.

In this blog I’m going to concentrate on software architecture issues.

Right now I’m working on applying the concepts of SOA, which tend to be more business and IT oriented, to modernizing a packaged software application. I’ve been learning a lot and I hope to pass on a little of what I learn as this product evolves through it’s natural life.

Thanks for reading my blog.