Programmers are guys who write business processes into stone with a kind of invisible ink. The better you tell them what your processes are, the better business results you will have. They are not people who model the world into code because they have no clue how the model works. They will come up with a well-engineered version of the reality they are coding if left alone and that will have to be the way you run your business if you don't tell them how the business works. It will likely more resemble a massive robot rather than a enabling friend.
I've recently completed a series of classes that involved business analysis, ITIL, and programming. Sometimes, I think about the subjects in depth and explore the details. Sometimes, I like to bring all the thoughts in alignment if possible and see the relationships. This time I got a good set of cross linked ideas that help look at what processes are from the business activity on down to the automated processes of a OO program.
As a programmer instructor, I talk about the recognition and the reuse of a set of statements that become a method (or function or procedure). As a business instructor, I teach the same thing concerning recognizing a process that you find useful and promoting the use of it into a larger group of people. As your process maturity level grows, the process grows from your own use, to people using it around you, to even more people until it's a company-wide standard.
Those same maturity steps are used to develop large scale architectures that provide guidance to the necessary design of the infrastructure that has implemented it. In fact, it's the principles of good design that have produced an architecture that works for the business. Sometimes business doesn't know which architecture to choose or isn't able to strategically point the direction and then takes the low road of design by infrastructure. This is the choice to buy instead of build and results are good as long as you stay compatible with the other components that are added on. Again what you end up with is a well-engineered solution without regard to your specific business needs.
The business processes that exist within a coordinated automated system or an infrastructure are essentially the programs that are being executed. They have been structured so that they achieve a specific objective. They take inputs and turn them into outputs. They have a specific trigger. They are layered into automated roles and responsibilities to work well when they have to be maintained. Just like it was an employee, you can fire an architecture layer and hire another version of that layer that fits the bill when managing a cohesive set of responsibilities in a business.
As far as I know there's not as much business writing going on for how to design a job role with few dependencies to other job roles but one of the common axioms of being promoted in business is that you must make yourself replaceable or else you'll never get out of your job. That's the same kind of thinking as when programmers say they must make their programming units reusable or maintenance will become more of a headache.
Process
If processes equal computer programs then they must have similar features. They can be broken down into smaller processes. They are either ongoing processes or processes that have well defined starts and stops. Processes can update policies, standards, guidelines, activities, other processes, procedures and work instructions if needed just like computer code can generate other code, update rules, and modify data that change how the program operates. A program is made up of activities, procedures, and work instructions or as the programmers know it, the class, the methods, and the program statements.
Metrics for a process are built in from the start and can be injected into computer code or built in to the abstract base of the code. In business, the best place to think about your metrics for success design patterns. I admire Peter Coad who tried to assign roles to classes and discover some reusable patterns for interactivity and not just static recipes. is during the planning stage so you can always build with them in mind or else you'll have trouble retrofitting them later. Roles of who should be involved in the process are important. In code, the types of relationships that you maintain with other code is important and successful relationships are spelled out in recipe books called
Process improvements are always a part of all processes and can be found in wrap-up sessions or project post mortems. In code we get a closed feedback loop from the folks who are using the programs who give us reason to enhance the program and get more financing for the next maintenance project. Feedback comes in the form of new or improved features and it gets added to the system as the value becomes known.
- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug
