Value Drives the Best Tech and User Collaboration
My post on Overcoming Language Barriers facilitated some very nice sharing of resources. Executives and managers! You need to familiarize yourself with this information; you will benefit through improved understanding of what your IT projects should be doing for you:
1. Excellent discussion on Domain Driven development from Sensei at ActiveEngine’s Cool Stuff post. This is more than a software development discussion- it deals with how to attack problems from a value perspective as you develop “language” between technologists and users. I suggest reading the transcript and paying close attention to Eric Evans’ thoughts- great reading.
2. Great, and thankfully brief, agile software development glossary from Alex Howard via Margaret Rouse at IT Knowledge Exchange. Agile projects have proven their value- get a leg up on this value-driven approach to software development.
As a teaser, here’s some of what Sensei and I had to say about the Domain Driven development discussion:
Sensei: you may be aware of a movement within agile called Domain Driven development. The basic idea is that you allow the “problem domain” to drive the efforts of your technology development and implementation…in Domain Driven development the starting point is the business processes and logic; the database and screens become secondary considerations.
However – and this is a big however – the domain must be defined in very clear terms….developers must be able to write, in English, what the problems are using the business units language. It is also critical that it is written clearly so that the intent can never be misunderstood. Some may argue that UML does this, but most customers’ eyes will glaze over when presented with Use Case diagrams. When the problem domain can be described succinctly in common terms, your problem solving sessions will be more effective.
My theme lately with the development teams I work with is to build a working vocabulary; that is, pick one term to describe a process and stick with that term. In these sessions I have had to literally ask “And the word we use to describe this process is …?” ….if you are jumping from problem to problem, or worse, from project to project, you need strong definitions to keep things straight.
Bob: I scanned the Eric Evans interview; easy and good reading for non-technical people to understand that software developers should want to work on VALUABLE system changes; i.e., very interesting in that he justifies domain expertise as enabling focus on valuable-to-the-business processes which can be much more complex than the other areas because they tend to be revenue producing and customer facing. I enjoyed the discussion about new system complexity requiring an “anti-corruption” layer to interface to the legacy system that could take as much resource as the new system. Also asking “why are you buying this” to get at where to focus modeling efforts. The multi-language (technical model, user model, reconciled language) issue sounds just like what happens when two people speaking different languages begin to understand each other- my last experience like this was in Korea. Excellent insight into the minds of software developers!
Do you have these types of discussions with your IT people? Is a software development process driven by the business processes that are of high value to the organization a good strategy? Why or why not?
Don’t miss a post! Subscribe via RSS or EMAIL.
One of the business groups who can be the best partners for creating the vision for the product, and I am sure I will be taken to task for this, are the sales groups. They tell what is necessary and sufficient and will be brutally direct. The draw back is that some times each sales individual has his or her own problem domain and are not concerned with the others as a whole.
For detail and good understanding of finance processes the accounting groups are the generally the best to work with, as they deal with rules in the daily business with S-Ox, SAPM’s etc.
In the general, the PMO groups are the best driver for coalescing the right enterprise level champions around a large project. They exceed at defining the goals and exit criteria for a project and have good tools for categorizing a prioritizing activities. Also, the PMO folks are really good at spotting common threads of importance that interlace many disparate activities or business functions.
I will date myself with this next statement: Back in the ‘90 (oh my gosh the last century!!) the PMO and IT projects were more tightly coupled. Generally it was the IT guys who used structure charts or data flow diagrams to map business processes with IT vocabulary. Very rare was it when the business community would pull our a chart. Today project management methodologies are more prevalent and the PMO folks do a lot of the domain definition. That’s a good thing. The down side is that IT is considered more of a commodity, and in some cases this is false assumption as the processes specific to company are found in software sitting on a shelf.
Wow, my comment was almost as long as your post!! ;)
Sensei- interesting in that I’m trying to write shorter posts, but it’s hard to do. Your comment length reveals your passion about the subject. We both seem to appreciate improving collaboration and understand between the non-IT and IT groups. Having worked with sales teams throughout my career the phenomenon of directness combined with “latest issue” focus is a constant- I experienced it when attempting to poll many ERP sales groups for software product improvements. Could you elaborate on “as the processes specific to company are found in software sitting on a shelf”? Does this mean that the IT group can play a valuable role in innovatively applying previously built modules?
Actually I made a typo. I meant to say “as the processes specific to company are NOT found in software sitting on a shelf.” In other words, if you have a process that is unique to your company you will have to construct something yourself to implement this process. That is, if your competitive advantage is unique to internal processes, that software will not exist anywhere but at your company. If internal IT resources can build and maintain that software you will keep the competitive advantage proprietary.
Sensei- I was hoping that there was something behind that- like an innovative approach to using previously built software. Yes- uniqueness to be competitive is an interesting problem when upgrading packaged software. Most of my experience is working for software vendors so we would be looking for the unique, hopefully broadly appicable, innovations. Usually the “user” types didn’t mind telling us about them, while the IT groups were more aware of their proprietary value.