Wake Up Call for the Banking Industry

Date: February 2014

In a discussion thread on the LinkedIn group Simpler IT, Marc Lankhorst mentioned that the Dutch Bank (The Dutch banking regulatory board) recently came out with a new report that discussed the stability of Dutch banks. The report is titled Naar een Dienstbaar en Stabiel Bankwezen or To a Serviceable and Stable Banking System (as translated by Bing.)

Appendix 7 of the report discussed the critical relationship between banking IT systems, Enterprise Architecture, and complexity management.

(continue reading <here>)

The Math of Agile Development and Snowmen

Date: November 2013

I was recently asked about the relationship between Agile Development and Snowmen. If you aren't familiar with The Snowman Architecture, see this earlier blog.

I'm not sure The Snowman Practice has much to offer Agile on small projects (say <$1M). These projects always seem to do reasonably on their own. However once a project goes much above $1M, the Agile approach can no longer keep up with the increasing project complexity.

(continue reading <here>)

The 3000 Year Old IT Problem

Date: July 2013

It was first described 3000 years ago by Sun Tzu in his timeless book, The Art of War.

We can form a single united body, while the enemy must split up into fractions. Hence there will be a whole pitted against separate parts of a whole, which means that we shall be many to the enemy's few.1

This is the first description of a problem solving technique that would be named 600 years later by Julius Caesar as divide et impera. Or, as we know it, divide and conquer.

(continue reading <here>)

SIP and TOGAF: A Natural Partnership

Date: May 2013

If you have ever heard me talk, you know the standard three-tier architecture is a bad approach for large complex IT projects. It has poor security. It is difficult to modify. It is highly likely to fail.

Instead, I recommend the Snowman Architecture. This architecture is great for large complex IT projects. It has excellent security. It is easy to modify. And it is highly likely to be delivered on time, on budget, and with all of the functionality the business needs.

I often show pictures contrasting these two different architectures, such as this:

(continue reading <here>)

The Snowman Architecture (Three Parts)

Date: September 2012

As Enterprise Architects, there is no lack of problems deserving of our attention. We need to ensure our organizations are well positioned for the Cloud, can survive disasters, and have IT systems that can chassé in perfect time with the business.

And then there is the whole area of IT failures. Too many of our systems go over budget, are delivered late, and end up depressing rather than supporting the business. If you have been reading any of my work, you know all about this.

But what if there was one approach to architecture that could meet most of our needs and solve the lion's share of our problems? I believe there is. I believe there is a single architectural style that is so important, I consider it a fundamental enterprise architectural pattern. I call this the Snowman Architecture.

This blog is in three parts:

  • Part I: Overview (click <here>)
  • Part II: The Economic Benefits (click <here>)
  • Part III: The Technical Benefits (click <here>)

The Misuse of Reuse

Date: July 2012

The software industry has been pursuing reuse for at least four decades. The approach has changed over that time. It started with structured programming promising reusable snippets of code. We then moved to object-oriented programming promising reuse through inheritance. Today we are focusing on service-oriented architectures promising reusable services that can be written once and then used by multiple applications.

For forty years we have been pursuing reuse and for forty years we have been failing. Perhaps it is time to reexamine the goal itself.

(continue reading <here>)

The Equation every Enterprise Architect Should Memorize

Date: March 2012

In my white paper, TheMathematics of IT Simplification, I gave the following equation for calculating the complexity of an IT system

C = F3.11

where C is the complexity in Standard Complexity Units (SCUs) and F is the number of business functions implemented within the system. As I point out in the paper, F can be either business functions or dependencies on other systems. An SCU, by the way, is the amount of complexity in a single business function unconnected and unrelated to any other business function.

(continue reading <here>)

SIP Complexity Model

Date: October 2011

SIP, as you probably know, stands for Simple Iterative Partitions, a methodology for finding the least complex solution to a complex IT problem. I have written about SIP elsewhere, for example, in my White Paper The Mathematics of IT Simplification. My goal in this blog is to give a high level description of the model SIP has for IT complexity.

(continue reading <here>)

New Word: Simplility

Date: October 2011

I am introducing a new word into the IT lexicon: simplility. Simplility is defined as the intentional architectural design of simplicity into a software application

Simplility follows a long tradition of "ilities" such as portability, reliability, and scalability. These all imply that somebody has made an intentional decision to include specific attributes in an application. Nobody expects an application to be portable, reliable, or secure by accident. We understand that it take skill and effort to give an application these attributes. And we understand that there are important reasons for doing so.

(continue reading <here>)

Public or Private Cloud? Wrong Question!

Date: October 2011

Many people are asking if it is best to use a public or private cloud. They are asking the wrong question.

The bigger issue for most organizations is not whether to use a private or public cloud, but whether to use any cloud at all. The issue here is not whether the cloud is a good idea or a bad idea, but whether the organization has sufficient maturity to make effective use of any cloud. Most don't.

(continue reading <here>)

Defining IT Complexity Terminology

Date: May 2010

My specialty is understanding how to measure, locate, and eliminate unnecessary IT complexity. One of the difficulties of this field is terminology. You would think that a word like simple would be simple to define. But there is no widespread agreement on what the words related to complexity mean.

(continue reading <here>)

The Failure of Success

Date: April 2010

I have written quite a bit about the cost of IT failure, most recently in a white paper. A number of people have criticized my analysis saying that just because a large project "fails" in the sense of being late, over budget, and/or not delivering expected functionality, doesn't mean that the project doesn't deliver value.

(continue reading <here>)

The Fundamental Flaw of Complexity Management

Date: December 2009

As systems add more functionality, they become more complex. As systems become more complex, the traditional processes we use to manage those systems become more strained. The typical response on the part of those building these more complex systems is to try to understand how to scale up the processes from those that can handle simple systems to those that can handle complex systems.

(continue reading <here>)

The Problem With Standish

Date: October 2009

In my recent white paper, The IT Complexity Crisis, I discussed how much IT failures are costing the world economy. I calculated the worldwide cost to be over $6 trillion per year. You can read the white paper here.

In this white paper I discuss the Standish Chaos numbers, but many readers have continued to question whether my conclusions are in agreement with Standish. I think my conclusions are in agreement, but I also think the Standish numbers are flawed. So I have mixed feeling about them. Let me explain.

(continue reading <here>)

Attacking Architectural Complexity

Date: October 2009

When I advocate for reducing the complexity in a large IT system, I am recommending partitioning the system into subsystems such that the overall complexity of the union of sub-systems is as low as possible while still solving the business problem.

To give an example, say we want to build a system with 10 business functions, F1, F2, F3, ... F10. Before we start building the system we want to subdivide the system into subsystems. And we want to do it in the least complex collection of subsystems.

(continue reading <here>)

Why I Focus On Complexity

Date: October 2009

When it comes to IT failure, there is no lack of "the usual suspects". We can look to failures in project definition, project management, and needs assessment. We can point to flawed architectures, implementations, and testing procedures. We can focus on communications failures between the business and IT, between IT and the user community, and between different business units.

Yet given this extensive collection of failure factors any of which can doom an IT project, why do I focus almost exclusively on the issue of complexity?

(continue reading <here>)

Three Rules for IT Simplification: Small, Separate, and Synergistic

Date: July 2009

The most important factor in building a successful IT project is simplification. Simplification means that the overall system should be as simple as it can possible be while still delivering the goals of the project.

In general, there are three rules you must follow to build a simple IT system.

  • Keep it small.
  • Keep it separate.
  • Keep it synergistic.

Let's take a look at each of these.

(continue reading <here>)

Factors Driving System Complexity

Date: April 2009

IT Systems are failing at an alarming rate and the rate of failure is increasing. Approaches that we have used in the past to successfully deliver IT systems are no longer working.

Something has changed: the complexity of the systems. It should be no surprise to anybody in IT that the complexity of the systems we are being asked to build has dramatically increased. The only surprise is that we have not adapted the processes that we use to build IT systems to take into account this increase.

(continue reading <here>)

The Cancer of Complexity

Date: March 2009

After many years in IT, I am convinced that code complexity is a relatively unimportant issue. This may sound strange, coming from someone who is always reminding people that Complexity is the Enemy. How can I not care about code complexity?

What is much more important than code complexity is how that code is architecturally organized. We can deal with complex code if that code is well sequestered. It is the effectiveness of the sequestering rather than any pockets of code complexity that will determine the complexity of the larger system.

(continue reading <here>)

Carving up an Enterprise Architecture

Date: November 2008

Melissa A. Cook recently published an article in ComputerWorld titled Enterprise Architecture: Lessons from the cutting board. In this article, Melissa likens developing an enterprise architecture to cutting up a chicken for dinner. She gives three lessons for creating an enterprise architecture.

(continue reading <here>)

The Job of the Enterprise Architect

Date: November 2008

ZDNet recently published an article on My Awesome IT Job: Enterprise Architect, IBM. The article is an interview with Martine Combes, an Enterprise Architect working with the CIO Organization of IBM in France. In the article, Martine says, "It is very easy to become overwhelmed by complexity and it is very difficult to maintain simplicity, especially when the scope is large, the number of team members is high. So better to have a simple architecture from the start, clearly showing the benefits for the Business."

(continue reading <here>)

 

The Future of Enterprise Architecture

Date: October 2008

Kristian Hjort-Madsen recently posted a blog entry about the future of Enterprise Architecture in the government. Having done some work on architectural simplification for several public sector clients, this got me thinking about not only the future of EA in the government, but the future of EA in general.

(continue reading <here>)

Can an EA be "correct"?

Date: October 2008

In a recent blog, Nick Malik asserted that EA is not about building apps right, but is about building the right apps. And that the correctness of an EA was a point of view.

This was my response:

In my view, EA is not about either building apps right OR building the right apps. It is about creating a structured framework within which meaningful and collaborative dialogues can occur between the business and IT groups. The term that I use to describe this "structured framework" is Enterprise Architecture.

(continue reading <here>)

How Not To Make IRS Systems Secure

Date: January 2008

The GAO recently came out with a study (GAO-08-211) that highlights a problem that is frequently associated with IT complexity: poor security. The GAO, for those of you who are not familiar with it, is the United States Government Accounting Office. This is the organization charged with making sure that the U.S. Government is spending our tax dollars wisely.

In this report, the GAO severely chastised the Internal Revenue Service for “pervasive weaknesses” in the security of the IRS IT systems. According to this report, these weaknesses “continue to threaten the confidentiality and availability of IRS’s financial processing systems and information, and limit assurance of the integrity and reliability of its financial and taxpayer information.”

(continue reading <here>)