September 2006
Monthly Archive
Consistent Architecture through Facilitation
Posted by Chris Sterling on 29 Sep 2006 | Tagged as: Agile, Architecture
Recently there was an email on the Scrum development mailing list regarding how to keep a common, consistent architecture which is maintained and used throughout multiple Sprints without someone designated as architect. Here was my response:
I would consider myself a software architect with quite a few projects under my belt. I started using some Agile techniques before I knew what Agile, XP, or Scrum were. I ended up finding myself working more on getting teams to collaborate and come to decisions based on good information rather than prescribing a particular architecture approach. As I have come to find out over many years, there are many approaches to architecture (as in design) that can work in particular contexts. Just as OO development and design patterns are not the best way to develop software in every project (such as real time systems and device manufacturing), so to is it not the case that architecture (more than minimal design) is needed.
“Disclaimer”:
—
Before I go sticking my foot in my mouth, the following scenarios are generalized and probably overkill for most organizations. Stick to the least amount of controls that will keep enough chaos for your particular needs. I am working with a company right now in which we are possibly implementing some of what is discussed below. They have an existing “Architecture”-based organization and we are trying to help them become more Agile. I hope that the topics discussed below are helpful in thinking about your organization but if not I wouldn’t be surprised.
—
I run a local chapter in the Puget Sound (Seattle) area of the IASA (Int’l Assoc. of Software Architects) and will be facilitating discussion and breakout activities on how Agile and architecture teams work together. There is more information on this at http://www.solutionsiq.com/iasa.html. There are multiple disciplines within the “Architecture” realm such as Enterprise (more business focused), Infrastructure (more hardware / facilities focused), and Solutions (more application/data focused). Each of these perform a service based upon a perspective of the organization which I believe can fit well with Agile.
“Potentially about the original email”:
—
If the Solutions Architect can be closer to the team (potentially on the team) to help in the development of the product that could be very helpful. We want to make sure they are prepared to be a member of the team and not a special case. If the rest of the team can understand and somewhat agrees with the architect about their ideas then that person will automatically get respect from other team members. It is also good if the architect can be coached on how to incorporate the ideas of others into the design, potentially on less critical areas, to help foster respect across the team.
As for the “not coding” aspect of this, I think this may be a concern overall. I just conducted a training session on TDD where one of the attendees, whom we coached to implement Scrum and Continuous Integration already, wanted to make it clear that design was needed. We tried to make sure it was understood that design was still done, whether it was through the automated unit test code or on paper napkins translated into test code, but that decisions about platform, frameworks, and services may not be needed from the start. We should implement in the simplest form first and then refactor to a desired design which may over time incorporate what is thought of as software architecture design. It was very difficult to get this point across entirely but I believe it can be learned over time.
This may be the situation that you are in. How do you facilitate that learning about keeping good design even though it is emerging throughout the product development life cycle. One way that I sometimes facilitate this is by giving the problem context to the group (possibly the solutions architect group) and have them figure out how they can best work in this model. Allow them to be skeptical of the model and answer their own questions. You may need a coach for this if you do not have somebody who feels comfortable speaking about architecture design and it’s use in Agile development.
—
“To further the Architecture and Agile discussion”:
—
The Solutions Architect is closer to the implementation of products/projects within an organization. They are a good fit to be team members on a particular project, a mentor for teams using new technology, taking tasks on multiple team sprint backlogs (hopefully not all at the same time), and providing communication support to the Enterprise Architecture group (feedback loop for potential best practices, issues with vendors, etc…).
An Infrastructure Architect “may” be close to the implementation teams at times and have their own long-term vision, short-term goals, and possibly running multiple Agile projects. They need to align closely with the teams, Enterprise Architecture group, and possibly product teams to make sure the vision and goals of the Product Owner and supporting cast (SME, customers, analysts). We still need to think about deployment in large organizations in order to keep it manageable, supportive of product delivery, and cost effective.
The Enterprise Architect tends to be a helper in the translation of product vision into attainable goals. The problem with many implementations of EA within organizations is that it is quite prescriptive in managing vendor, platform, processes, and data choices. This can put a strangle hold on the potential output of the entire organization and is a large burden on the EA group itself. In my experience, an EA may be a good choice as the Product Owner mostly in large projects. They understand how to remove potential integration dependencies, how business functions with technology, and the higher level picture of the business. They can help in the discussing all of these important items with the implementation teams to help them in making better decisions with a bit of Product Owner training and further understanding of Agile values and principles.
—
I am quite interested in hearing other people’s views on this and any constructive criticism about the content. This topic can get quite deep and have so many potential scenarios that I have discussed here but if we keep our eyes on the Agile values and principles we can figure out how we can work together better. Thanks.
Comments Off on Consistent Architecture through Facilitation
Need-Driven Design as an Integration Strategy
Posted by Chris Sterling on 25 Sep 2006 | Tagged as: Agile, Architecture
As we develop software, it is common to design before we code. On average, I have found that the more time between when design occurs and the actual implementation is developed, the more unexpected detrimental effects surface. A common reason for design problems when integrating external dependencies into a project is that the project team was using what was available from the integration dependency instead of deciding on what they needed and mapping that to a solution. Design by contract made a step in this direction by supplying the idea of a contract between a supplier and client.
Over the past few years, we as an industry have started turning a corner towards a more business driven approach to software development through Agile values, principles, and methods. As we develop software we must take the same business driven approach to design. As anybody who has used Test-Driven Development (TDD) knows, design is a continual part of our development cycle. We design our software through the creation of well defined criteria (tests) and refactor our code mercilously to an acceptable design. Another interesting aspect to TDD is the YAGNI (You Ain’t Gonna Need It) principle which states that one should never add functionality until it is necessary. Instead of designing towards the use of an external dependency we should only integrate upon need. This is why I have coined Need-Driven Design as the business driven approach to software integration design. Need-Driven Design has the following steps:
- Only add external dependencies to your project when the value outweighs the integration costs
- Integrate external dependencies into your project at the last reasonable moment
- Define a well defined interface for interactions with systems which may be out of your project’s full control
- Develop executable criteria for expected interactions with the an interface implementation
- Create integration criteria which meets the expected interface intent and integrates with the external system dependencies
An example of this approach to software design is a project which needs data from an exposed web service. In this example, the web service returns an XML represntation of a customer with the following information:
- Customer Name
- Company
- Address
- Job Title
- Phone Number
The business has informed us that this external system is the most up to date view of our customers and therefore must be used by the application. This satisfies step 1 of our Need-Driven Design approach. Next, we should develop enough code to know that we need to interact with the external system and where that interaction is going to occur in our application which satisfies step 2. The business case for this example is that our end users must see the customer name, company they work for, and a phone number to reach them at. For this business case, we define an interface that returns only the customer name, company, and phone number which as you can see is less information than the web service returns. After defining the interface to satisfy step 3, we should create executable criteria for interactions with the implementation of this interface and our application. We can use mock objects to do this through the setting of expectations across multiple tests with variable response message signatures. This may lead into the development of validation functions, exception handling, and defined results packaging. This executable criteria from step 4 can now be used as the intent for consuming the exposed web service. Automated integration tests should be developed as criteria for implementing the defined interface for external web service consumption. This will not be a replica of the interface tests defined using mock objects. These tests should make sure that the consumption of the external system dependency maintains the integrity of the defined interface intent described in those tests.
By driving our integration strategies through the steps defined in Need-Driven Design we can decrease integration costs, reduce coupling to external dependencies, and define business driven intent into our applications. Integration can be a headache in development, design, testing, deployment, and operations. Through the steps in Need-Driven Design, we can assure those that pay for maintenance of these integrations get the value they need.
A New Blog Focus
Posted by Chris Sterling on 24 Sep 2006 | Tagged as: Agile, Architecture, Scrum
For quite a few years now I have been working in the software architecture and Agile space which may seem like an oxymoron to some. I got asked the other day, from somebody who knew me for both, what type of reaction I got from the XP community members when I brought up the word “Architecture”? Honestly, I had gotten some rolling eyes, criticism, and the usual YAGNI blurb. It hasn’t affected what I am doing and I keep closely aligned with the Agile Manifesto and the Principles behind it. So how can I work with anything regarding software architecture and still be “agile”?I have found that in some cases the guidance provided through higher level views of systems has enriched the product delivery. Definitely it is not needed in every case and I will freely admit that the “Ivory Tower” approach to software architecture is mostly misguided. There are the cases in which you do have a need for infrastructure and enterprise architecture. But instead of the “Ivory Tower”-type teams, these groups could be more in line with the product delivery cycle. I was amazed the first time that I had an Enterprise Architect work as the Product Owner of a Scrum project. The EA had a great ability to manage communication from business customers into the product backlog. The EA could help breakdown multi-team work with minimal dependencies and integration points. The EA was able to have great negotiations with the team regarding new information learned during a sprint. I was amazed at how well it worked. Then I thought about it and these are the skills that many of the EAs I have worked with and respect had already.
Along with EAs, the Infrastructure Architect is still needed in certain contexts to help in large scale deployment configurations. I have heard of instances where this team can run Agile projects and incorporate Lean principles to remove waste such as duration to deliver in the supply chain. Instead of taking the approach that “this is how things are” we can decide on how things “should work” and then work towards that. If it takes 2 months to procure a server for our staging environments then we should be asking ourselves why? What would stop us from being able to deliver on these server requests in 1 week? Sometimes we don’t take a step back and look at these options. If we do, we might just find out that we can increase the productivity of our entire organization.
I have been holding these two spaces, Agile and Architecture, away from each other for the most part but I am going to change that. Agile and Architecture are compatable and I will continue my quest to promote my findings on this topic, good or bad. Just remember that I am not speaking about the traditional Architecture role but rather what I have found as an Architect that works. An Architect is not a role which is the “know it all” in designing an application for teams of developers. Prescriptive approaches to working with development teams can be characterized as intrusive and misguided. We must understand how we can help in the true guidance of a team doing their work and delivering on goals.
Comments Off on A New Blog Focus
