Working in the dark

By |2008-08-30T16:05:33+00:00August 30th, 2008|Enterprise Architecture|

If we listen to smart people who create development processes, we hear things like "collect requirements" and "understand business process."  We then go and write use cases, design software components, and write code.  Test cases describe the things we are going to test, and automated tests allow us to test our systems over and over.  Build scripts and deployment scripts and maintenance scripts automate complex tasks.  Whew!

There’s a lot of stuff in there.  And that is just the software development process.  But software development is part of a much larger process. 

When you start to consider the end-to-end processes, you have to consider the planning and operations aspects.

Planning includes things like business strategies, trends, business programs, scorecard measurements, metrics, scenarios, business capabilities, high level business processes, business functions, divisions, roles, teams, budgets, roadmaps, and rollout plans. 

Operations teams have even more considerations, leveraging things like configurations, change plans, incident reports, problem statements, service levels, events, assets, and services.  Assets include servers, systems, components, databases, and network components. 

Why the litany?

I’m trying to make a point.  Many people are involved in running a business, and many are involved in making changes to the business, ostensibly to improve it.

If you write software, or work in IT, you are part of that system as am I.

But if we don’t understand, even on the surface, the entire system by which the business operates, we are working in the dark.  We can’t see how our work affects others, and we can’t see how important (or unimportant) it is that we perform our responsibilities well.

Most importantly, without seeing the system, it is tempting to make things up. 

For example: If we don’t see how the requirements we gather connect to the business processes, we might be tempted to ignore the processes and simply invent requirements that "make sense" … to whom?  the project manager? The customer representative?  What makes the requirements "correct" if we have nothing to connect them to?  I’ve seen this happen many times.  It is crazy, but typical.

Another example: if we don’t see how our services are connected to enterprise information models, we can’t see if we are creating a service that avoids unintended consequences, or would create problems for managing data, or requires a process to "Magically" come into existence, complete with staffing and expertise, that the business is not expecting.

It is critical for the people involved in software development to understand the entire system of corporate operations, even at a visceral level.  IT teams must have access to the system of processes, especially as that system changes over time.

Over the next few months, I expect to be writing more about this understanding… How to see the system, and how to connect your parts to the "whole." 

There is a lot to understand, and learning is a process.  Each day, I consider myself a student, and a day is well spent when I did two things: used my understanding to help someone, and learned something new.  As I write, I am learning, so I’m inviting you, gentle reader, to share this journey with me.  Share the things you have learned, and the perspectives from your own experiences. 

Instead of working in the dark, let’s light some candles…

Traceability, the Solution Model, and Metamodeling

By |2008-08-26T11:05:42+00:00August 26th, 2008|Enterprise Architecture|

It is nice to point out, on occasion, when two different leaders in the architecture community are saying things that, when added together, become greater than the sum of their parts. 

First off, my friend and colleague Gabriel Morgan recently described the business value of creating a single underlying model to connect all aspects of a particular software project (from requirements through code).  He calls the model a Solution Model, and rests that model firmly on a metamodel that allows these underlying elements to be related to one another in a useful way.

His blog post, which is long and richly detailed, is not about modeling.  It is about value.  I recommend it highly.

"this blog is about understanding the value of modeling to a project team and is focused on helping Solution Architects gain a practical understanding of the value of modeling to, in turn, help explain its value to the project team for adoption." (Gabriel Morgan, from his blog)

The other contributor is Jean-Jacques Dubray.  He recently posted a very interesting article on "Model Driven Engineering" where he discusses many things, including the value of a metamodel.

"My recommendation to developers and architect is: metamodel (as a verb), metamodel completely and thoroughly and even if you don’t create a [Platform Independent] model of your solution and a compiler (based on this metamodel), write code with the metamodel in mind (this will end up looking like a framework of course). For instance, define precisely what a business entity is, an association, a business process, a task… Remember, you are NOT creating an OO model, you are creating a metamodel. Every solution domain has a metamodel. There is nothing absolute about it, the metamodel of an information system is different from the metamodel of an industrial process control system, and what works for a travel company may not work for an insurance company." (Jean-Jacques Dubray, from his blog)

What makes these blogs interesting is not that they are about the same thing.  They are quite different from one another.  What makes them interesting, together, is the deep and fundamental support that each provides to the practice of "using the metamodel."  This is a term that is not discussed much, but it should be.

The metamodel is the conceptual information architecture that classifies the information that we can use to construct solutions, understand problem domains, and create practices that insure that we build the system that we should build.  As JJ points out, the terms matter.  As Gabriel demonstrates, those connections are valuable.

The metamodel is key.  With it, we can tie the requirements to the design in a way that supports agility.  We can say, definitively, what the impact of a change in requirements will have, allowing us to select the requirements that we want to change in order to have a desired effect.  This is powerful, and necessary.

And it all starts with the metamodel.

Technorati Tags: ,

Malik's Laws of Service Oriented Architecture

By |2008-08-21T12:46:00+00:00August 21st, 2008|Enterprise Architecture|

  • No one but you will build the services you need in time for you to use them
  • If you build a service that no one else asked for, you will have built it for yourself
  • If you build a service for yourself,  you will optimize it for your own use
    • It is therefore the optimal service for you to use
    • It is very unlikely to be the optimal one for anyone else to use
    • No one besides you will use it
    • You will not use anyone else’s


Therefore, any team building reusable services must build each one only after two or more people have asked for it, with full knowledge that the resulting service will almost certainly be available too late for any of them to use it.

Therefore, no team should intentionally build reusable services.

Additional Laws and Corollaries

  • If you invest in improving someone else’s pre-existing service, you will create a reusable service.
  • Creating a reusable service, be improving someone else’s service, will cost you more, up front, than writing a completely new one.
  • The cost of maintaining a service increases proportionally to the number of consumers that use it.

Merging EA Frameworks

By |2008-08-05T11:01:00+00:00August 5th, 2008|Enterprise Architecture|

I’ve spent some time of late looking at various EA frameworks.  Nothing perfect out there yet, but quite an array of useful things.  But what would it take to create a single consistent framework for the IT profession?  Let’s look at the stuff that’s there now.  (Caveat: I reserve the right to be wrong.  If you disagree with anything here, send me an e-mail and I’ll update the text).

  • TOGAF – Basic strength: solution architecture.  Various models and how to create them.  Basic weaknesses: Planning methods and governance framework.  Weak on Information Architecture
  • FEAF – Basic strength: complete implementation tied to measurement framework.  Basic weaknesses: very specific to government, lack of independent process taxonomy keeps processes “in the silo.” 
  • eTOM – Basic strength: excellent process taxonomy with rich details. Strong information architecture.  Great for governing external vendors.  Basic weaknesses: fairly specific to telecom industry, gaps in governance and enterprise architecture models. 
  • ITIL – Basic strength: excellent process framework for operations and (now) governance.  Basic weaknesses: no architectural methodology to speak of.  Sizeable gaps in information or application architecture.
  • Enterprise Unified Process – Basic strength: soup-to-nuts coverage of enterprise software development processes, including funding and operations.  Basic weaknesses: poor adoption rate and lack of a governing body to allow for growth, minimal architectural methods, no enterprise process or capability framework.
  • Zachman – Basic strength: comprehensive taxonomy of architectural artifacts (to let you know when you are done).  Basic weaknesses: Lack of published and vetted methods to avoid “boil-the-ocean” exercises and focus on one particular benefit.  Very shallow: No detailed process, capability, or solution frameworks for “level 2” detail.  Highly proprietary.

What would an ideal framework look like?  It would have all of these things.  This list is “off the top of my head,” so I’m going to miss a few, but this is where I’d start:

Capabilities / Measurement / Process model for the enterprise

Capability and process modeling take a huge hit when trying to create an enterprise model just to create the base taxonomy.  A published taxonomy, governed by a passionate community, is necessary to get enterprise architecture efforts up to speed in non-Fortune 500 organizations.
Service, Solution, Feature and Technology model Application simplification and portfolio management require a base taxonomy of solutions and technologies to align the work in various divisions and speed up adoption of integrated solutions.  An industry standard taxonomy is necessary to allow vendors to provide useful information up front and smooth the development of SOA services across the enterprise.
Detailed process descriptions for all aspects of IT If wishes where horses, I’d merge ITIL and TOGAF and EUP and MSF and Agile processes to get a consistent, community governed, richly detailed process model for all aspects of Information Technology governance, processes, and measurement.  Include measurement, planning, improvement, transition, operations, and introspection.  Takes a “business of IT” approach.
Rich architectural methods and training for all aspects of architecture Starting with TOGAF, I’d extend the ADM to cover, in rich detail, three subtypes of architecture (collaboration and measurement across the enterprise, governance within a functional unit, solution design and development) across three architectural “areas of focus” (business capability and processes, information design and integration, solution development and technologies).  It is simple to create this “table.”  Doing so allows us see the opportunity to fill out the ADM.
Richly detailed “Business conceptual model” Everyone has their own ideas of what basic business terminology means.  A community governed business conceptual model can be governed by, and provided to, business schools around the world to create and maintain consistent information models.  This removes one of the key causes of software project failure: failure to share common context.
Multiple federated “common information models” Some industry implementations of EA frameworks are already here, and some vendors provide a good starting point for the shared elements (for common, shared processes).  A framework to allow not only many models, aligned by industry or attributed types, but also to allow organizations to create and manage federated models within their own walls to manage their unique value proposition while keeping their information models aligned.

The frameworks that are there are just not ready to do everything.  Only by describing what ‘everything’ would look like can we begin to fill these gaps.