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…

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

3 thoughts on “Working in the dark”
  1. Hello Nick,

    I am planning to write a book about this topic (at least for myself). I saw the light few years ago and now I am convinced about it. The answer is…process is everything.  So the problem is to consider all components as "a list" which you are doing.  The answer is to look at through a specific context in order to create a model for understanding how it all works.  So the context is process.  At macro level all companies have same set of processes.  Therefore, we can even create common "information meta-model".  With process meta-model and information meta-model we can rapidly develop enterprise meta-models for processes and information..thus understand how to apply SOA concepts into IT developments.

    You have lots of good thinking in your blog!  I will keep visiting.

Leave a Reply

Your email address will not be published. Required fields are marked *

2 × four =

This site uses Akismet to reduce spam. Learn how your comment data is processed.