Software development processes have long advocated structuring a software solution around a domain model of the problem space being automated. A domain model shows how our business processes add value by progressing the states of our key business entities. These entities and their life histories tend to be much stable over time than the processes that surround them. Modeling the entities and their states enables us to experiment with different ways of achieving the same outcomes (state progressions) as we seek to rationalize and automate these processes.
So, why have we never thought to build a good domain model of the software projects at the heart of our software development processes? At IJI we started building such a model some four years ago and this model now forms the heart of our process kernel around which we built the Essential Unified Process. One key motivator was to model the value that different development practices and processes can / do / should provide so that we could enable our customers to evaluate and select between different ways of achieving the same outcomes.
Agile Development
The Kernel Journals 2: An executable model of software development
I first learnt about the power of domain models more than 25 years ago when I first applied the Jackson System Development (JSD) process. This approach involves modeling the key conceptual entities in the problem domain and the business rules that define how value is delivered by advancing the value states of these key entities. Add a few key business attributes and you now have an executable model of your problem domain / business. You can then simulate the execution of your business merely by slapping some rough-and-ready user-interface screens onto these entities.
Read More
We Care!
How many people know that approximately 40% of the cost of a truck are software costs or that it takes millions of lines of code to develop a mobile phone? The answer is unfortunately, very few. People do not view these things as software products! Software exists in so many things that we touch on a daily basis, but it is hidden under the shells of pacemakers, cars, etc., and the amount of software included in a “normal” product, grows every second.
Is the fact that it is hidden, the reason why so many software projects fail or run over time and budget? Do decision makers realize how much money could be saved if they just cared a little more?
Well, we care! We know that project deadlines can be met, that project budgets can be kept and that the customer can receive what they expected. You just have to be smart and care a little more. Ivar Jacobson International supports an organization called Swedsoft (www.swedsoft.se) whose primary goal is to care about the software industry, the hidden software industry.
Do you care?
How do we get business and IT to play on the same team? by Ivar Jacobson
Agile Development | February 8, 2010
Tweet
To close the gap between business and IT we need to get them to play on the same team, as said in my two previous blogs. I compared this team with a soccer team in which the participants are not just specialists but also generalists – they can all kick the ball when called upon.
The Business-IT “team” should work in a similar way. Despite having specialized roles, all of the participants should contribute to achieve a common goal in order for everyone to be successful.
But do they? If they were a soccer team they would probably not win many, if any, games. Extending the soccer analogy, the business often acts like the absentee owner who wants the team to win but does not really want to take the time to be directly involved. Instead they try to micro-manage from a distance, demanding a detailed play-by-play plan for who is going to score and when, and they berate the team for not adhering to the plan. They will say that they will provide players (business representatives and product owners) but the players they assign are usually absent because they are too busy doing other things. As the team owner, they also don’t want to spend too much to hire the best players and coaches, but they still want to win against teams that are willing to spend more. Read More
Detox, Slim Down and Shape Up – Becoming Lean and Agile
I was celebrating my birthday in Japan with a team I mentored. The manager was present and he asked me politely what my birthday wish was. I said I wanted to slim down without thinking much. It was something I wanted, but had not been succcessful. But through the weeks following that, by being conscious about calorie intake and output, spreading my food intake, reducing portions, adding some exercises, my weight reduced dramatically. I call it "dramatically" because I never lost that much. Within about a month, I lost 8 kilograms, and then another 6 the next month and another 6 on the third. I had to buy a new pair of pants twice. There were no dieting pills, no starving myself, no gym, but just some self-control, having daily stand-up meetings with my weighing scale and food calorie labels and of course some discipline and commitment with encouragement from weight logs. Read More
Agile Use Cases + Visual Studio 2010
We all know that Ivar Jacobson is the father of Use cases and that Use cases are a great vehicle for describing requirements. What many developers also know is that Microsoft’s Visual Studio has been a great management tool to enable team members to continuously collaborate providing comprehensive source control, code checkout and bug tracking tools. But what about developing Use cases in Visual Studio as a requirement – not as something you track such as a bug or defect? Read More
Let the Business and IT play on the same team by Ivar Jacobson
Agile Development | December 19, 2009
Tweet
In an earlier blog (Nov 2009: Closing the Gap between Business and IT) I described the gap between business and IT and suggested a way forward: we must speak the same language. That language must be more than just a spoken language; some simple drawings or models are often useful. However, beware of business models inspired by software models, which assume an underlying abstract computational machine. We must work together pursuing common goals and results - without resorting to passing documents from one side to the other. And we must deliver high-quality results on regular intervals.
Forrester says we should have a “fusion” of the business and IT, going beyond mere alignment. The idea is sound, but it is better to get them to play on the same team together and win.
Reflecting on 2009
Our new ‘corporate’ blog has been launched and I think the timing couldn’t be more serendipitous. As we come to the end of 2009, it is definitely a year that has caused quite a bit of reflection in the business and IT world. The world economic crisis forced many organizations to focus on the basics and ensure that core business was operating effectively and efficiently. Aligning IT to business became critical as every investment dollar was scrutinized. At IJI, one of the ways the business and technical teams align is by ensuring we’re communicating better as a team focused on a common set of objectives – the new blog is just one result of that strategy. Read More