Working in the dark
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...
Comments
Anonymous
September 03, 2008
Great topic for a series of posts Nick. I am looking forward to hearing your thoughts on this issue.Anonymous
September 03, 2008
I always learn more from failure than from success.  In that spirit, I'll share a (small) failureAnonymous
September 08, 2008
The comment has been removed