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...
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.
Implication
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.
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
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).
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
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.