There is a lot of discussion today regarding Service Oriented Architectures.  With SOA, systems are designed to expose services so that other clients/applications can consume them.  The resulting system is loosely coupled and the services can be distributed to produce a more flexible system.  

Typically when people talk about SOA and services they are discussing the technical services – the interfaces such as web services that provide access to a particular function.    Examples of such functions include checking an account balance online or using a remote graphics service to create a bar chart given a set of data.

But what about Business Services?  What are they and are they part of SOA?  How do they relate to technical services?  A business service describes something of value that an organization provides its customers, or something that it uses from another organization to provide its own services.   

Business services are at a higher layer than technical services within a SOA architecture.  A business service can be provided by a person or people, by technology, or most often by people who use technology.  When technology is used, there could be several software services that support a single business service.

There is often confusion between the terms capability and service.  If you search on the Internet you will find that there are many views about these two terms and their relationship.  I like the view that describes the service as providing access and the means to use a capability.  Two hospitals may have the ability to perform surgeries, but only one may have the ability to perform Liver Transplants. The service, Liver Transplant, delivers the effect of using capabilities, where the capabilities are made of the organization’s skills (Liver Surgeons, Hepatology Specialty, etc.) and tools (Surgical Suite, CT scans, Ultrasound, etc.) that enable the service. 

My company recently performed a business architecture engagement for a new cancer center.  The work involved understanding how several oncology departments work independently and how they will work together using a multidisciplinary approach in the new center.  We captured a business motivation model, organization models and process models, for the as-is and the to-be states.  We created an accompanying strategy simulation for cancer center planning.  These models are discussed in greater detail in the Business Modeling book.

In addition, we created a business service model as it relates to organizations and locations. This model was not covered in the Business Modeling book and our intent on the project was to understand what services are provided by each department and at which location, and to identify the dependencies on other services.  Then we worked with the departments collectively to determine what services will be provided at the new center, what are the service overlaps, and what gaps exist if the services they depend on are not offered there or nearby.  For example, if in order to provide certain pre-op or post-op services there are dependencies on a phlebotomy service there are three choices, offer phlebotomy service at the center, provide transportation for patients to another location, or change a process so that blood work must occur before or after the appointment.

We have produced a complete business service architecture for a cancer center offering.  We created a classification framework that also identifies each service as billable or non-billable, as mission or non-mission critical, as core to the business, or context – one that is not a core capability and could be outsourced.  This allows for the creation of service groupings so that an organization can determine which services are an important part of its business where investment is warranted, and which services are not as critical and could be outsourced.

We found the business services to be one of the most useful business architecture artifacts as it provided insight into how an organization views its business and helped identify critical gaps.   The resulting architecture serves as a baseline so that other cancer centers that are undergoing transformation can be compared to ensure proper coverage of issues and analysis.

I work in big sales. Sales is of course the business function of convincing customers to exchange money for goods or services. But what is big sales? Big sales is simply a question of size: when a customer pays at least $10,000,000. Selling a Ford Explorer to Joe Sixpack is sales. Selling a fleet of 10,000 Ford Explorers to Hertz is big sales. Selling a new credit card to Joe Sixpack is sales. Selling IBM on providing American Express to all their employees: big sales.

The line between sales and big sales is not precise. There is no sharp difference between a $9.5 million deal and a $10.5 million deal. Rather there is a gradual continuum between regular everyday sales and the larger deals.

But big sales are truly different from regular everyday sales, different in a number of ways. First, the customers are different. An individual person buys a bag of groceries for $40, a computer for $1100, or a car for $27,000. But the big sales customers are not individual people. Few people pay $10 million for anything in their life; few have the money. Instead of individual people, big sales customers are big organizations: companies and governments. For the most part, only big companies and governments have the money to make big purchases.

Second, big sales are interactions between teams, not individuals. When Deloitte sells an accounting system installation to Chevron, a team of people at Deloitte make the sale, and a team of people at Chevron make the purchase. Multiple people are involved on both sides. Multiple stakeholders at Chevron must be convinced.

Third, big sales take time. Much time elapses between the initial meeting and the day the deal is inked. At least months elapse, sometimes years. Big sales have long sales cycles. When Accenture sells Visa International new IT system for approving credit card transactions, the sale takes more than a year.

Fourth, big sales are never anonymous. When a Ford dealership sells a new Explorer to Joe Sixpack, the dealership may know very little about Joe. But when Bechtel sells construction of a new subway line to the Washington Metropolitan Area Transit Authority, Bechtel knows WMATA well. There are Bechtel employees whose sole responsibility is to understand WMATA, to know all the key employees and decision-makers, and to understand WMATA’s challenges as well as WMATA does. Joe Sixpack is a customer, but to Bechtel, WMATA is a client, an organization known intimately.

Fifth, big sales have complex effects on the procuring organization. When British Airways buys a fleet of new A380s from Airbus, the procurement has significant and complex impacts on BA. Their pilots must learn to fly the new jets. Who will train? When will they train? What is the impact on the existing routes? The BA mechanics must learn to service the new jets. Who? Where? The new jets will fly some routes, and not others. Which routes? What schedules?

At least British Airways flies jets today, and so understands many of the complexities of acquiring a fleet of A380s. These are known complexities. When the United States Border Patrol acquires a new surveillance system, there are not only many complex effects, but some of these effects are unknown. How should Border Patrol change their staffing: what skills do they need more and what less? How should Border Patrol change their training? How will drug trafficking organizations adapt their tactics to the new surveillance, and hence what should Border Patrol do differently to adapt to those new tactics?

Finally, big sales often fail to launch. Safeway does not worry about customers entering their stores, filling their shopping carts with groceries, and then changing their minds and leaving without making a purchase. But it is common for a big company or a government to spend years planning a big procurement, to decide on the vendor, to negotiate a deal, and then before signing the final agreement, to decide not to purchase anything after all. The big procurement is judged to be too risky: better to not launch now.

Simulations are useful for purchasing organizations. With a simulation WMATA personnel could explore different strategies of subway construction. Should the eight new stations be opened all at once, or should one station be opened at a time, as they are built? Which routes should be underground and which above ground? When should roads be closed to permit construction, and which roads? What roads should be rerouted for the subway, and when?

Simulations can provide cost estimates for the different WMATA alternatives. But just as important as cost estimates are nonfinancial results. How much inconvenience and traffic delays does the subway construction incur on the driving public? How popular is the resulting infrastructure? What is the impact—positive and negative—on the surrounding retail?

Simulations conquer complexity, allowing people in a procuring organization to better understand their options. Simulations are also uniquely useful for helping a group of stakeholders reach as decision. As Ron Zahavi and I describe in our book, simulation models can be used in a model-based workshop, allowing all the stakeholders to collectively arrive at a decdision. Ideas can be tried, and results can be shared.

Finally simulations lower the risk of a major procurement, both the actual risks and the perceived risks. Working with a simulation leads to a better understanding of the consequences of the purchase. Better understanding means lower risk.

Simulations are useful for procuring organizations but today they are rarely built for this purpose. Procuring organizations do not spend the time and money to create a simulation around their major procurements. Who has the time and money?

Sellers do. Sellers have the time and money to create procurement-oriented sims. Sellers know their products, the alternatives for the customers, and the tradeoffs involved. Sellers know their clients, and understand the details of the clients’ problems. And sellers have the motivation, to reduce the likelihood of a failure to launch.

We call this model visioning, creating simulation models for big sales. Model visioning sims help customers understand the ramifications of major procurements. Model visioning sims increase the likelihood that a customer will act. Model visioning sims increase the likelihood that a customer will make the right decisions.

I work in big sales, creating model visioning sims.

Last week, the Climatatic Research Unit—one of the world’s leading institutions devoted to the study of climate change—suffered a leak. Someone anonymously released thousands of previously secret CRU emails and documents to the internet. Since then, critics of the CRU—including global warming skeptics—have found embarrassing materials among the leaked files. Some emails appear to advocate changing measured temperature data to better fit global warming arguments. Other emails discuss pressuring academic journals to reject papers skeptical of global warming. Still other emails recommend deleting models and data files rather than providing them to a Freedom of Information Act request. The Daily Telegraph has (inevitably) dubbed this scandal Climategate.

What does Climategate mean for global warming? Is the scandal a “smoking gun” as some have suggesting, showing that man-made global warming is not occurring, or perhaps only occurring slowly? Or is it a “tempest in a teapot”, as others claim, certainly embarrassing for the scientists involved but ultimately providing no evidence against man-made global warming? Frankly I don’t understand the science deeply enough to have a useful opinion. But no matter what it means for the science and politics of climate change, Climategate offers lessons for us, for those of us who use models to persuade.

As we describe in our book, business models are used for eight purposes. One of those purposes is analysis, using a business model to gain insight, insight about customers, regulations, productivity improvements, or whatever. Another purpose is persuasion, using a business model to change someone’s mind. Models are used to persuade customers to buy, to persuade stakeholders to invest, and to persuade employees to commit.

CRU created models, models of climate of course, not models of business situations, but models nonetheless. They used these models for both analysis and persuasion. They used their climate models to analyze temperature data, as part of the scientific process, ultimately publishing academic papers based on their analysis. And they used their climate models for persuasion, to convince other scientists, politicians, the media, and the general public that the world is warming, and that fossil fuel emissions are causing that warming.

The CRU kept their models secret. They did not provide them to global warming critics in the scientific community, and in fact they did not provide them to supporters in that community. No one outside CRU had access to the models.

Secret models are fine for analysis. But secret models fail to persuade. Skeptics ask why they should believe the results of your model, if you won’t share it with them. How do I know you haven’t cheated in some way, created a model that simply supports what you want rather than one that is independent of your desires?

So the first lesson of Climategate is share your models. Make the models available to anyone who wants them. And in particular share your models with skeptics. The skeptics are the people who most need to be convinced, and they are the people who are the least likely to be convinced by secret models.

Among the leaked CRU documents were model files, software code that implements the CRU climate models. As outsiders slowly pore over the code, they have found many issues of professionalism: poor programming practices, apparent bugs, and comments that indicate that a later model developer does not understand the code written by an earlier one. These professionalism issues with the CRU models have provided skeptics with more reasons to be skeptical. If the CRU follows poor programming practices, how can we know that the results are accurate? If the CRU personnel who are responsible for the model code do not themselves understand it, how can we outsiders trust it?

The second lesson of Climategate is ensure that your models are professional. Models meant to persuade should be easy to understand, exhibit best practices, and of course be free of bugs. Reasonable people may disagree with the assumptions contained in the models, but those same reasonable people should not have cause to question the professionalism of the models themselves. Only professional models persuade.

The CRU relies on temperature data from many different sources all over the world, collected over many years. Some of the data was collected more than 100 years ago. Altogether the CRU assembled millions of individual temperature measurements. But this raw data was collected by hundreds of different organizations, with varying equipment and varying disciplines. Before the data could be analyzed, it had to be statistically adjusted and normalized, so it could be properly compared.

Since the leak, the adjustments themselves have become controversial. No one is denying the need to do statistical adjustments, but some climatologists have accused the CRU of always adjusting in ways that increase the amount of apparent global warming. They claim that the raw data shows much less warming than the adjusted data, that the global warming is an artifact of the statistical adjustment process not the climate.

There is no easy way to compare the adjustments that the CRU made to other potential adjustments that could have been made to normalize the data. The CRU made assumptions about the adjustments, and perhaps those adjustments were reasonable, or perhaps the assumptions themselves introduced bias. There is no easy way to know.

So the third lesson of Climategate is make it easy for others to change the assumptions. When I create models to persuade, I provide a user interface of assumptions, giving skeptics the ability to change the assumptions I made and understand the effect of each assumption on the outcome. Allowing skeptics to provide their own assumptions is critical to convincing them.

What if the CRU had learned and applied these three lessons? First, they would have given their models to everyone who wanted them. The models could not have been leaked if they were not secret in the first place. Second, the CRU models would have been professional, free of bugs and easy to understand. Doubts about the results of the models would have been averted. Third, the models would have included assumption user interfaces, allowing critics to understand how different assumptions would have changed the outcome.

I suspect that global warming would have been contentious no matter what actions the CRU had taken. The stakes are large—trillions of dollars and thousands of lives—too large to avoid controversy. But certainly if the Climatic Research Unit had learned these three lessons of using models for persuasion, they could have avoided much of the Climategate mess they are suffering today.

I have been noodling lately about the problem of strategy execution. Some organizations know what they need to do, and they know why. But they cannot seem to do it. They cannot make the process changes required to execute the new strategy. (Have you ever worked for such an organization?)

The recent book Strategy and the Fat Smoker is about strategy execution. Its clever title compares the problem of strategy execution to the difficulties faced by fat smokers.  Today, every fat smoker knows he should change. He knows that he should eat more salads and less ice cream.  He knows he should exercise more and watch less TV. And he knows he should quit tobacco. He knows what he should do, and he knows why. He just cannot manage to change his behavior.

Of course there are significant differences between failures of personal strategy execution—like the fat smoker’s—and failures of organizational strategy execution. All organizations are political, and what is best for the organization as a whole is always worse for some business unit, or some function, or some group. Somebody always loses. And the (prospective) losers will lobby hard to prevent the changes required.

The 2004 book Predictable Surprises looks at failed execution of disaster prevention, organizations that knew what to do to prevent a predictable disaster, but that failed to take the appropriate actions. Bazerman and Watkins—the authors of PredictableSurprises—examine some disasters in detail, and probe into why the disasters were not averted. One disaster they examine is the 9/11 terrorist attack. For 20 years, several government agencies were aware of the increasing violence of jihadists, and their increasing willing to strike at distant infidels in the US as well as nearby infidels in Israel, India, Egypt, etc. For 20 years, the FAA (and other government agencies) was aware of weaknesses in air travel security, including the very tactics used by the 9/11 jihadists. The authors claim that 9/11 was not in fact a “failure of imagination” (as famously described by the 9/11 Commission) but rather a failure of execution: the Gore Commission knew what to do in 1996, but could not manage to execute it, particularly in the face of opposition by the airline industry and by Congress.

Can business modeling (and simulation) help? I suspect so, but I am not sure. That is my noodling topic. The business modeling techniques we describe in our book are certainly useful for figuring out what to do, and how to do it. But the four modeling disciplines we describe are not particularly useful in actually changing behavior once the what and the how are known and accepted. We need something additional, a simulation discipline that explicitly addresses the inherent politics, that allows different groups within the organization to make their cases, and that induces action.

In part one of this two-part article I discussed how business models can help a school system select the set of features most important to it in a school student management system. Such an application allows teachers to manage student attendance, grades and calendars, and provides students, parents, teachers and other school administrators the ability to collaborate.

Business models also help software developers at a student management system vendor create the right application. For example, instead of describing that a daily calendar is a requirement, we begin with the business models. What is the need for the calendar? What is the motivation for deploying it? Who will use the calendar and how will it be used (if teachers, parents, students use it , what is the process for each)? How will the calendar change the user experience? The answers to these questions will ensure that we deploy the best solution for the need.

But software developers are often removed from the client and user. To help them design the application they are often given some form of use cases, descriptions of how users will interact with the application. Sometimes the requirements are in the form of the list of functional requirements detailing what the system must or might support (for example “The system shall provide a daily calendar”.) The software developers have to interpret the requirements and design the application. But if they don’t understand what is driving the user, if they don’t understand some of the user issues or what the process is for using the application, they might interpret things wrong, or in a way that the users won’t like. The application won’t meet the user’s expectations and the users won’t like or accept the application.

The developers need to bridge the requirements as described in the business models to the application they are to implement. They need to map the business activities to features that support the activities. Through studying the processes teachers use to manage their day and to schedule and grade assignments for periods they teach, the developers realize that  teachers desire a daily calendar based on periods, not on hours of the day.

In part one of this article I described a school system that on odd days switches periods 4 and 7. But another school system might have the same 7 periods each day in the same order 1-7, while another might have periods 1, 3, 5,and 7 on Mondays, Wednesdays and Fridays, and periods 2, 4, and 6 on Tuesdays and Thursdays. Since each school system has a different set of periods, and periods that start and end at different times, the application should be flexible to accommodate these variations.

Business models provide additional critical information to the application developers. They provide a context, a business context for the technical requirements. The software developer can visualize how the user will use the system and by understanding more about how the application will be used, the developer can build or select the right set of features.

When an organization selects an application or system to meets it needs there are two aspects of that selection. One is from the perspective of the organization acquiring the system and the other is from the perspective of the supplier of the system. The organization must understand its needs and requirements and select the features that are most essential to its business. The vendor supplying the system must ensure that what is developed meets the needs of its prospective clients. If the wrong set of features is developed, a mismatch will occur.Business models help with both aspects. They help organizations understand their strategy and goals and map the essential capabilities they need to support those goals. Business models also help in the software development process. They help developers better understand what features their clients need and how they will use those features. In the first of this two-part article I discuss how business models can help organizations select the right solution.

In traditional technology initiatives, such as the acquisition of an application, requirements are gathered and handed to vendors so that they can develop or configure the application to match the requirements (we discuss the topic of business models and software requirements in chapters 1 and 12 of our book.) The requirements are sometimes in the form of use cases and sometimes in a list of “shall” and “may” functional requirements (for example “the application shall support 100 concurrent users.”) However, traditional forms of requirements such as these do not convey the strategy of the organization or which requirements represent the most essential features.

Business models are a crucial part of the requirements gathering and definition phase as they help us capture the business view from the subject matter experts that know the business. We can capture the business motivation for a new application, and for each individual feature of the new application. We can capture whose work the application supports, what activities the supported users perform, and which of those activities are to be supported by application functionality.

For example, many middle and high schools today in the US are in the midst of deploying new technologies for managing student data and tracking student performance. Almost all teachers submit grades to the county level where it is processed by some application, but many teachers are still maintaining student data such as attendance and grades in notebooks. The review of student assignments is a manual activity, not supported by any software. The recording of the grades is a manual activity today, but in the future the teachers will use the new student management systems for this activity.

Student management systems are applications that typically manage student assignments, grades, attendance and school calendars and announcements. Such systems may be standalone applications used by teachers in schools, or they may be web-based, offering access to teachers, school administrators, students, and parents. Most colleges in the US use such systems today and many state counties (particularly those with high income households and high personal computer and web use) have begun using or experimenting with student management systems at the high school (grades 9-12) and middle school (grades 6-8) levels.

In the US most county school systems have very small IT departments. IT staff move from school to school to troubleshoot local computer problems but they don’t have the ability to develop large applications themselves. The decision to purchase a student management system often occurs at the county level where it is decided that all schools in the county must use the same applications. Sometimes individual schools decide to experiment with a particular system.

The development and deployment of a student management system has many requirements. Such systems may provide teachers with the ability to record attendance, record grades, let parents and students track performance, provide a calendar and collaboration capabilities, and more. Schools in the US today face tightening budgets and funding is often tied to student performance. They would like to deploy a technology that will help them but which features should they deploy?

Student performance can be tied to the ability to track student grades and intervene early if needed, but it is also tied to parental involvement. If a choice has to be made between features, should notification of dropping grades be implemented, a calendar showing assignment due dates and test dates, or a collaboration capability allowing all users to message with each other, or maybe a combination of these?

Business models can help the school system determine which features they need most to help them select the right student management system from a vendor. A business motivation model tying improved performance goals to metrics and tactics might indicate that early parental and counselor intervention is crucial and a facility is needed to send alerts based on conditions such as dropping grades. This capability along with a calendar allowing parents to know what assignments and tests are coming would be a better choice for the school system at this time than investing in messaging or collaboration features.

An organization model showing that a particular teacher teaches several versions of the same course in different periods, along with a business rule model for how a particular school system manages its periods during a week provides much more information than a simple requirement for a calendar. Only through the understanding that their schools need a flexible calendar system that allows periods to start at 8:03 and end at 8:44, and that supports the policy that on odd week days periods 4 and 7 are switched, can a school system avoid acquiring a system that has a simple daily calendar with on-the-hour period start and end times.

In the second part of this article I will discuss how business models can help vendors and software developers better understand their client’s needs.

We are in the midst of the world’s first recession caused by modeling, a model-driven recession.

We are certainly in the middle of a recession, a declining economy. Some think this downturn is the beginning of a depression, comparable to the depressions of the 1930s or the 1870s. Others think this will be more like the typical post-WWII recessions, lasting 1 or 2 years.

Every recession is different, with different causes, different dynamics, and different outcomes. For example, the 1990-1991 recession was triggered by the oil price shocks of the first Gulf War, and by the failure of 747 savings and loan associations.  (I oversimplify. At the risk of stating the obvious, the American economy is enormously complex, the most complex human-constructed artifact in world history. There are no single causes for anything.) How did today’s recession happen?  This recession started with the big banks and other financial institutions in New York.

In the course of their everyday business, big banks buy securities and take other financial positions. All of these positions carry risks, risks that the positions will decline in value, become worthless, or even lead to large liabilities. Banks attempt to manage their risks, both by limiting the positions they take and by hedging their positions with other positions, positions that will gain value when the former positions lose it.

Starting in the mid-1990s many banks began to use a new form of model to manage their risks: value at risk. VaR models attempted to measure the riskiness of a position in terms of a 1% worst-case. A VaR value of $1 million means that there is a 1% chance of losing more than $1 million on a particular position. VaR values are computed both for individual positions and for portfolios of thousands of positions taken together. Banks used VaR models to determine how much risk they were taking, and how they should hedge that risk. (The business journalist Joe Nocera explains the history behind value at risk, how the banks adopted these models, and what happened next.)

Unfortunately VaR models are fundamentally flawed. There are several problems with value at risk, but the biggest problem is the implicit statistical assumption that financial markets behave as normal distributions. The normal distribution is of course just the good old bell curve from elementary statistics, an accurate model for some phenomena: for example, men’s heights. But normal distributions are known to be a poor model for the price fluctuations of financial instruments. Extreme movements are much more likely on Wall Street than in a normal distribution. (Power law distributions are a better model of financial markets.)

So VaR works fine, except when the markets change quickly. David Einhorn compares VaR to “an airbag that works all the time, except when you have a car accident”.

The consequence of banks using VaR models to manage risk is that they systematically underestimated the risk of big losses. They saw their portfolios as substantially less risky than they turned out to be. Based on the model-driven overoptimistic assessment of the portfolios, the banks acquired more risky securities than they otherwise would have. Then when things turned, everything declined quickly. Once a bank started to experience a larger loss than it thought likely under its VaR models, it sold the assets, leading to lower prices for those assets, and bigger losses for everyone else who held those assets, or similar ones. The losses fed on themselves.

To some extent, this is a typical pattern for a speculative bubble and its subsequent burst. The railroad bubble of the 1870s and the following Panic of 1873 followed essentially the same steps. People were overoptimistic about the value of the railroads that many were building. Then when things turned, everyone tried to sell at the same time, prices declined, and panic ensured. But the bad models that drove the Panic of 1873 were merely in people’s heads; they were poor mental models, not poor computer models. Today’s recession is the first caused by computer models.

We business modelers can take some small comfort here. It was not business models that drove this recession. VaR is a model discipline of capital market valuation. VaR is about the chance that a given security will decline in value. VaR is not about models of corporate goals or processes or business rules, not the kind of business models we describe in the book. Their models were at fault, not ours.

And if their models got us into this fix, maybe our models have a role in getting us out. Phil Gilbert argues that we need to improve the productivity of white collar work to turn the corner on this recession. I think he is right. Historically the greatest increases in productivity have come during recessions. When times are good, everyone focuses on meeting the topline numbers, on selling more and then somehow delivering on what has been sold. Costs and productivity are less important. When times are bad, everyone focuses on the bottomline numbers, on somehow generating more earnings from the meager sales they are able to make. Costs and productivity rule. And since white collar work is vastly larger than blue collar work these days, increasing the productivity of white collar work is essential to improving overall productivity.

We can use business modeling to increase the productivity of white collar work, so fewer people create more value. For example, when business process models are executed in a BPMS, the work can be done faster, better, and more consistently. Our book is about the business value of business modeling, and much of that business value show up as white collar productivity.

In addition to improving white collar productivity, Phil also talks about increasing the transparency of white collar work. He says: “There needs to be a revolution in implementation of processes that bring greater visibility and less risk to all aspects of our businesses. It is no longer acceptable that senior management remain ignorant of the goings-on at even the deepest depths of the organization.” This identification of visibility and risk is new to me, but perhaps it should not be.  We all accept the importance of visibility in the public sector, as the premier means of preventing corruption. In fact the most influential anti-corruption NGO is called Transparency International—their very name reflects the link between visibility and the biggest public sector risk, corruption.

The growth of systemic risk in Wall Street over the last 20 years is not the same as public sector corruption of course. In fact, it is closer to incompetence than corruption. As Michael Lewis says “[Meredith Whitney] just expressed most clearly and loudly a view that was, in retrospect, far more seditious to the financial order than, say, Eliot Spitzer’s campaign against Wall Street corruption. If mere scandal could have destroyed the big Wall Street investment banks, they’d have vanished long ago. This woman wasn’t saying that Wall Street bankers were corrupt. She was saying they were stupid. These people whose job it was to allocate capital apparently didn’t even know how to manage their own.”

But there is a similarity between this model-driven stupidity about risk and simple corruption. Both rely on secrecy. Corruption relies on secret payments from (for example) a favored firm to a government official. The big banks relied on secrecy about the risks they were taking to achieve the profits they reported. If the risks had been visible to everyone—shareholders, other lenders, analysts, regulators—the banks might have avoided this mess.

Perhaps the mess was unavoidable, even with better visibility.  VaR might have driven the banks to make the same blunders, and just made those blunders more rapidly obvious to everyone outside. The increased visibility from business modeling can still help us grow the rest of the economy again. Most of the economy is outside Wall Street, outside of the financial service industry entirely. Those businesses need better visibility of their business processes, the business rules they are using, and the goals and objectives they are trying to achieve. Our business models can deliver that kind of visibility. With that visibility we can turn the corner on this model-driven recession.