November book review: Learning to See

Mike Rother, John Shook
Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA

Find this book on Lean.org

A value stream is all the actions required to bring a product or a service to a consumer. Value-stream mapping is a tool used to visualize and analyze the flow of materials and information in a value stream. Value-stream mapping identifies the sources of waste in a value stream and helps you improve the whole system, not just its individual components.

In Learning to See, Mike Rother and John Shook highlight the differences between "Push", which produces according to a schedule, and "Pull", which produces only what the next process needs when it needs it. They explain why "Push" results in overproduction and other types of waste and offer their guidelines on how to introduce a lean value stream that generates the shortest lead time, highest quality, and lowest cost:

  1. Produce to your takt time. Takt time is the customer demand rate divided by available working time per day.
  2. Develop continuous flow wherever possible. Continuous flow produces one piece at a time with each item passed immediately from one process to the next.
  3. Use supermarket pull systems to control production where continuous flow does not extend upstream: for example, when a process has too much lead time.

    Use a sized FIFO ("first in, first out") lane to maintain the flow when supermarket systems are not practical: for example, when we cannot create an inventory of all parts such as during custom development.
  4. Try to send the customer schedule to only one production process. This process is called pacemaker: it sets a pace for all upstream processes and requires all downstream processes to be connected in a continuous flow.
  5. Level the production mix: distribute the production of different products evenly over time at the pacemaker process.
  6. Level the production volume: create an "initial pull" by releasing and withdrawing small, consistent increments of work at the pacemaker process. Consistent increment of work, aka "pitch" or "management time frame", will help you establish your takt time.
  7. Develop the ability to make every part every day or every pitch in processes upstream of the pacemaker process.

The authors also included a list of questions designed to help you create future-state value-stream maps:

  1. What is your takt time?
  2. Will you build to a finished goods market from which the customer pulls, or directly to shipping?
  3. Where can you use continuous flow processing?
  4. Where will you use supermarket pull systems?
  5. At what single point in the production chain will you schedule production?
  6. How will you level the production mix?
  7. What increment of work will you consistently release?
  8. What process improvements will be necessary?

These questions along with two manufacturing plant examples will help you develop and introduce your own lean value streams in your organizations.

Learning to See is a well-written must-to-read technical workbook on value streams. I recommend it to anybody interested in Lean. Happy reading!

October Architect: Domain Model Structure - Part 1

Problem Statement

In August, I blogged about the structure of a release unit's trunk folder. We looked at how to organize your .NET solution to support principles of object-oriented and domain-driven design and distributed application development. We recommended creating a separate library for domain model classes that would describe your release unit's capabilities in business terms.

This month, we are starting a discussion around how to organize classes inside your domain model in a clear, easy-to-understand and, thus, easy-to-maintain manner that supports natural growth of your applications. The topic is quite large and will take a series of articles to cover even at a very high level. The purpose of this article is to introduce you to the topic and provide basis for our discussion over the next few months.

Objectives

As always, let's define our main objectives:

  • Support on-the-project learning
  • Organize development of the domain model in a structured evolutionary manner
  • Have the domain model tell a story
  • Make rules and operations explicit and extendable
  • Support domain-driven design philosophy
  • Support principles of object-oriented design

Why are these objectives important?

Support on-the-project learning

When all decisions are predetermined before the implementation, a significant amount of business value is lost:

  1. Learning that occurs during the project is ignored because it is not a part of the original plan.
  2. Communication between users and stakeholders and the development team is poor.
  3. Very limited creativity takes place. There is almost no place for new ideas.
  4. As a result, the system is created lacking flexibility and understanding of the domain.
To get the most out of your projects, enable continuous functional and technical learning for all your team members. As they learn more, they will make decisions better and faster.

Organize development of the domain model in a structured evolutionary manner

There are two major alternatives to Structured Evolutionary Design:

  1. Big Design Up Front (BDUF), in which design decisions are perfected before the implementation is started.
  2. Adhoc Evolutionary Design, in which design decisions are made as the system is being developed, but without a set of rules that would ensure domain model consistency.
As your team acquires new knowledge, their understanding of the domain changes. Even if you start with BDUF, the domain model needs to evolve in order to correctly represent your understanding of the business situation.

As your domain model evolves, it becomes more powerful and sophisticated, requiring you to establish rules and guidelines around it. Without overarching rules, constant changes to the model will make it inconsistent and hard-to-understand, eventually leading to a familiar "fast-slow-stopped-redesign" application development cycle.

Have the domain model tell a story

An ability of the domain model to tell a story is one of the most critical design objectives. OO allows us to build classes representing real-world business concepts. Should not we be able to use them to describe a business situation? Ask the following questions during your next design or code review:

  • What business processes are enabled by this system and what are their steps?
  • What business transactions are supported and how are they implemented?
  • What business concepts do we deal with day-to-day? How are they described? How can they be created and loaded into memory?
  • What operations are performed? What decisions do we face? What business rules could be customized and how are they configured?

Make rules and operations explicit and extendable

Business rules and operations are often the most sophisticated and the most changeable classes in the domain model. But most importantly, these classes have a great potential to add a hidden business value. Make them explicit and extendable in your model to uncover their true power.

Support domain-driven design philosophy

If you are new to domain-driven design, please, refer to this book to get started.

Support principles of object-oriented design

There is plenty of information online about the object-oriented principles. They are a great way to maintain a clear, flexible, reusable, and robust codebase and keep infrastructural details outside of the domain model.

Summary

This article started a discussion around how to organize your domain model. We have reviewed the objectives and discussed why they are important. Next time, we will look closer into designing domain model in practice.

Happy coding! To be continued...

October book review: Essential WCF

Steve Resnick, Richard Crane, Chris Bowen
Essential Windows Communication Foundation. For .NET Framework 3.5.

This is a well-organized and easy-to-read introductory book on WCF. It provides a thorough overview of the principles behind building and consuming WCF web services and includes real-world examples illustrating how to leverage WCF framework in your applications. The topics covered in this book include:

  • Contracts: how to define complex structures and interfaces
  • Channels: how to configure channels and channel stacks
  • Bindings: how to choose communication protocols
  • Behaviors: how to manage instances, concurrency, and transactions as well as how to add your own custom behaviors
  • Serialization and Encoding: how .NET classes are serialized and represented on the wire
  • Hosting services in IIS, WAS, and managed .NET applications
  • Security options for authentication and transport- and message-level security for Internet and Intranet applications
  • Integration with other frameworks such as WF and Silverlight
  • Other topics: JSON, RSS/ATOM, peer networking, metadata publishing, diagnostics, and others
    • The authors did an excellent job explaining complex WCF concepts in simple terms and will help you jump right into building distributed applications in .NET. I highly recommend this book to .NET application developers and architects.

      Happy reading!

How to call MapPath in WCF services

While working with WCF services hosted in IIS7 with non-HTTP endpoints (such as TCP or NamedPipes), we realized that our usual way to resolve a phisycal file path corresponding to a virtual path on the web server is not supported.

In ASP.NET, we use HttpContext.Current.Server.MapPath method, but HttpContext.Current is null in WCF services with non-HTTP endpoints. What shall we do? It turns out that there is another way to map a virtual path: using the HostingEnvironment class. See the example below.

public static string MapPath(string path)
{

    if (HttpContext.Current != null)

        return HttpContext.Current.Server.MapPath(path);

    return HostingEnvironment.MapPath(path);

}

Happy coding!

Dave West speaks at OTUG on Wed, Oct 14, 2009

Who: Dave West
What: The Death of Agile - Business Ecology - and the Future of Software Development
When: Wednesday, October 14, 2009
5:30 - 6:30 PM Social Hour
6:40 - 9:00 PM Presentation
Where: Owens Science Hall, room 150 (3M Auditorium), University of St. Thomas, St. Paul, MN
Cost: $20. Free to all UST students, staff, and faculty.

See more information at http://www.otug.org.

Flash cards for GOF design patterns

I came across flash cards with class diagrams of GOF design patterns. The flash cards were created by Jason McDonald and are available for free download on his blog.

September book review: Flow

Mihaly Csikszentmihalyi
Flow: The Psychology of Optimal Experience

Mihaly defines flow as a state of mind when consciousness is harmoniously ordered and thoughts and actions are congruent with each other. People experiencing flow are fully involved in the activity and continue doing it for its own sake. The experience is genuinely satisfying. Nothing else seems to matter.

The author provides general principles and examples that illustrate how such experiences happen. He points out that the normal state of mind is chaos. Without training and without an external object that demands attention, it is hard to concentrate long enough to achieve "optimal experience". This presents a significant challenge for building an environment conducive to flow.

Mihaly offers a thought model to transform potentially entropic experience into flow. You can use it to make the job more enjoyable for your team members or to create online applications that provide flow to your users. I tried to summarize it in the steps below:

  1. Set clear feasible goals. These goals will recognize challenges present in the system and imply skills necessary for the participants to be successful.
  2. Find ways to measure progress. In order to develop new skills, the participants will need to pay attention to the results of their actions.
  3. Help the participants become immersed in the activity. To maintain their full concentration, match the demands of the system with their skills and limit the number of available options to a select few.
  4. Make finer distinctions in the goals and challenges and help the participants recognize the opportunities for action.
  5. Raise the stakes if the activity becomes boring.

Happy reading!

Domain Driven Design at .NET User Group on Thu, October 1, 2009

Jordan Terrell will be speaking on Domain Driven Design tomorrow, October 1, 2009.

Who: Jordan Terrell
What: Introduction to Domain Driven Design
When: Thursday, October 1, 2009
5:00 - 7:00 pm - Presentation
Where: Microsoft Corporation, 8300 Norman Center Drive, Suite 950, Bloomington MN 55437
Cost: Free. Register here.

No Architect article in September

There is no article in the Architect Column this month. I am very busy working on applications scheduled to go live in October. Thank you for your understanding and thank you for reading our blog!

A new kind of art?

Ksenia Symonova is a recent winner of the Ukraine’s Got Talent show. You might think that she is a singer or a dancer, but that is far from the actual case. She is a sand artist.

Take a look at a couple of videos below. They are amazing.

Welcome to ModelBlog

Thank you for visiting ModelBlog. We hope the time you spend with us will be both entertaining and worth your while. Have fun!

Authors

Search

Archive

Tags