Application Types (App Types) – The Early Years

Several years back, I did an exercise in mapping out families of application architectures and application types.  It was an extensive archeological expedition.

Key Goals / Outcomes
There were several goals of the exercise:

• Identify canonical application architectures and app types
• Figure out a useful way of sharing architectures
• Figure out whether it's better to focus on the business architectures or the technical architectures
• Find a simple way to overlay patterns work on top of technical architectures
• Find a simple way to share architectural styles
• Find a way to simplify and share visuals of end-to-end architectures

The exercise fed into a number of later works years later, including:

• Re-shaping the patterns & practices catalog to be organized using app types -- and this literally drove our product-line more formally toward app types (a pre-cursor to the patterns & practices "factories" effort in 2005)
• Identifying a canonical set of application types for the Microsoft platform as part of the Application Architecture Guide.
• Shaping the path of the home/hub pages on MSDN toward "deployment targets" and application types

Key Activities
Some of the key activities of this early exercise included:

• Creating an exhaustive catalog of application types grouped and sliced in various ways
• Interviewing many of our best application architects in the trenches
• Sanity checking with many of our top architects at head quarters, including Rico Mariani, Pat Helland, and Jim Gray
• Reverse engineering many available sample applications inside and outside of Microsoft
• Checking with industry experts on their lessons learned about the types and the shapes of all the applications they've seen and built over the years
• Creating an extensive inventory of application patterns from various sets of our  key customers that had a wide range of applications and platforms
• Evaluating competitive efforts to index and catalog application shapes and types, and making sense of various patterns efforts

Keep in mind, that going into this, I already had the benefit of doing more than 650 customer architecture and design reviews -- yet still, this was an overwhelming exercise.  It forced me to find new ways to deal with large bodies of data and information, and somehow turn them into  shared maps, browsable, reusable knowledge nuggets, and backdrops for deeper conversations and elaboration.

Lessons Learned from Architectural Exploration
Some of the surprises for me or things that I learned that I didn't expect include:

• Focusing on business architectures and verticals was less effective and less reusable than focusing on technical architectures as a baseline (from there, we could overlay business architectures)
• Knowing the deployment patterns was the fastest way to get a good sense of the application patterns (it's where the logical met the physical against the infrastructure)
• Looking through quality attributes as a lens made it easy to find and explore patterns for security, performance, reliability, manageability, etc.
• So many applications boiled down to simple CRUD (Create Read Update and Delete)
• The biggest variation among applications was the business logic and workflow
• IBMs simple model of user, process, and data was useful as one lens
• Views and viewpoints were a powerful way to change perspective and drill into another aspect of applications
• At a high-level, you could capture a customer's core system by capturing the data, workflows, and workloads (the workloads significantly shaped the design of the app)

In retrospect, the simplicity and common denominators of CRUD make a lot of sense.  It's all about interacting with information at a fundamental level.  People are just trying to get things done and there's only so many things you can do with information -- find it, browse, save it, share it, transform it, etc. as part of your workflow.

Early Map of App Types
I included one of the many early maps of the application types that helped us figure out what to throw out and what to keep as we moved forward.   One of the key distinctions that Ward Cunningham helped me figure out was to distinguish between the shape of the application architecture and design, and the actual “purpose” of the application.  Some purposes were more business-oriented, while some were more technically oriented, and this helped me find and distinguish different families of apps.

It's circa 2004, but the irony is how timeless the backdrop really has been.  It’s rough and raw, but like I said, it’s just one sampling of the many braindumps behind the scenes of mapping out app types.