Have you ever designed or purchased a new home? If so, inevitability there were some things that you look at after the fact and say why did we put this light switch here, or why does the door open this way? My wife and I designed our home and had it built a few years back. A part of that build process is a walk-through before anything is built, during this walk-through I was very aware of previous "issues" I had encountered in other homes and apartments I have lived in. The amazing thing is even though I was very conscious of this I still failed to get it right. We have this one switch that is on the left-hand side and having lived here for a while now I realize it should have been on the right-hand side.
How does this fit with the topic of the post? My profession is to come up with technical solutions to business problems that are easy to maintain and extensible for future changes. So do I get everything right up front? The simple answer is no; I must use the light switch or open a door the wrong way a few times to realize the problem with the design. Our team at Edge R&D has been working with a variety of businesses on software solutions for quite some time and have seen similar challenges everywhere we have been. We typically suggest to our business partners the use Agile methodologies and principles so we can prove our ability to deliver and let the incremental value prove that. Given this model of operating it is imperative we stay focused on building only what is required and quickly begin delivering on those commitments.
Recently we were discussing design options of a potential solution and walking a client through the proposed architecture. What we presented was an architecture that generally follows enterprise solution patterns, with our own spin on certain things to assist with maintainability. Additionally, we expressed the importance of following some design principles that help isolate changes that may occur to core dependencies that will likely change over time. We often refer to this approach to architecture as Emergent Design, a term I first was exposed to years ago by Scott Bain at NetObjectives while taking one of his training classes.
agileSherpa via Wikipedia says: "With emergent design, a development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge. This process continues as the organization continually delivers functionality. At the end of an agile release cycle, development is left with the smallest set of the design needed, as opposed to the design that could have been anticipated in advance. The result is a simpler design with a smaller code base, which is more easily understood and maintained and naturally has less room for defects"
To avoid a point of confusion we experience recently, emergent design does not equal emerging technology, it simply means that the best designs will emerge over time, as you learn, use, and work in an environment. You should constantly drive to keep a solutions design as simple as possible and refactor when it makes sense. When you find that the light switch is on the wrong side, figure out how you can move it to the other side, or in some cases put a motion sensing switch in.
Generally, the problems we run into are similar to past problems we have tackled. As a result, we often propose a conceptual architecture that we are familiar with and are confident will provide a solution that will ultimately solve the needs of the client. As we get into specific implementation details the expectation is there will be some discoveries and subtleties that will lead design modifications. In the end if we are constantly re-factoring and allowing the design to emerge within the agile delivery process the product we will become a solution that meets the client needs and provide them with a sense of ownership since they were involved from the beginning and have seen it evolve. All the while we invested the minimal amount of time on design specifically focusing on what was important to support the immediate business needs. We do our best to avoid painting ourselves or our clients in to a corner by trying to solve all problems up front, with the understandings that business priorities can change, systems are upgraded or replaced. All of these factors result in the realization that a single “pristine” point in time architecture often will not stand the test of time. With this in mind we focus on what we know today and ensure the design and architecture are following things such as the open/closed principle to help ensure the extensibility of the design and architecture.
How does this fit with the topic of the post? My profession is to come up with technical solutions to business problems that are easy to maintain and extensible for future changes. So do I get everything right up front? The simple answer is no; I must use the light switch or open a door the wrong way a few times to realize the problem with the design. Our team at Edge R&D has been working with a variety of businesses on software solutions for quite some time and have seen similar challenges everywhere we have been. We typically suggest to our business partners the use Agile methodologies and principles so we can prove our ability to deliver and let the incremental value prove that. Given this model of operating it is imperative we stay focused on building only what is required and quickly begin delivering on those commitments.
Recently we were discussing design options of a potential solution and walking a client through the proposed architecture. What we presented was an architecture that generally follows enterprise solution patterns, with our own spin on certain things to assist with maintainability. Additionally, we expressed the importance of following some design principles that help isolate changes that may occur to core dependencies that will likely change over time. We often refer to this approach to architecture as Emergent Design, a term I first was exposed to years ago by Scott Bain at NetObjectives while taking one of his training classes.
agileSherpa via Wikipedia says: "With emergent design, a development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge. This process continues as the organization continually delivers functionality. At the end of an agile release cycle, development is left with the smallest set of the design needed, as opposed to the design that could have been anticipated in advance. The result is a simpler design with a smaller code base, which is more easily understood and maintained and naturally has less room for defects"
To avoid a point of confusion we experience recently, emergent design does not equal emerging technology, it simply means that the best designs will emerge over time, as you learn, use, and work in an environment. You should constantly drive to keep a solutions design as simple as possible and refactor when it makes sense. When you find that the light switch is on the wrong side, figure out how you can move it to the other side, or in some cases put a motion sensing switch in.
Generally, the problems we run into are similar to past problems we have tackled. As a result, we often propose a conceptual architecture that we are familiar with and are confident will provide a solution that will ultimately solve the needs of the client. As we get into specific implementation details the expectation is there will be some discoveries and subtleties that will lead design modifications. In the end if we are constantly re-factoring and allowing the design to emerge within the agile delivery process the product we will become a solution that meets the client needs and provide them with a sense of ownership since they were involved from the beginning and have seen it evolve. All the while we invested the minimal amount of time on design specifically focusing on what was important to support the immediate business needs. We do our best to avoid painting ourselves or our clients in to a corner by trying to solve all problems up front, with the understandings that business priorities can change, systems are upgraded or replaced. All of these factors result in the realization that a single “pristine” point in time architecture often will not stand the test of time. With this in mind we focus on what we know today and ensure the design and architecture are following things such as the open/closed principle to help ensure the extensibility of the design and architecture.