There are three main principles, focal points upon which architecture should base its effort. The first is Connection to the organizational goals. Roughly, these come two categories. First, business goals that define what the company exists for and what place it has in the marketplace or society. Second, projects, business cases that define opportunities to further the first type of goals. For Connection principle, architecture needs to work on connecting the efforts and capabilities of IT with these goals and endeavors. It needs to thinks about how structures, technical solutions and infrastructures need to be organized to realize the goals as good as possible. Architects do have a role and responsibility here to understand the business aims and ambitions. And architects must make sure that other people in IT understand how to realize these aims and ambitions into concrete solutions.

IT is expensive. Period. That is not just a perception of the business, it is reality. We need to find ways to most efficiently use IT. One part of the solution is Cohesion in the kind of solutions created and deployed. By choosing from a limited number of solutions (reference architectures) we can keep the complexity contained. Cohesion also helps to organize the systems in a way that promotes sensible partitioning of functions and responsibilities, such that simplicity and flexibility are increased.

Change is a given, so we better be ready for it. Changeability is the last focal point of architecture. It is the capability of IT to adapt to changes in business goals and the environment quickly. Changes disturb the Connection between business goals and IT capabilities and it might disrupt the Cohesion in within IT. By focusing on Changeability we can restore Cohesion and Coherence as quickly as possible.

The effect of defining the role of architecture by these three principles is focus.
We gain focus on
• what needs to be done,
• what can be done,
• tangible results and delivery,
• quality,
• cost effectiveness

In short: focus on results that matter. It is interesting to note that these principles apply to architecture at multiple levels: enterprise, project, systems and infrastructure architecture are all governed by these principles. In that respect the three C’s of architecture do not only help unite business and IT effort, but also unite the different IT functions themselves.

This blog is the first in series about Lean Architecture, an architecture method that bridges the gap between classical architecture , Agile Project Management and long term goals of organizations.
The upcoming series will first focus on a series of Lean Architecture principles: basic principles or mantras that form the foundation of Lean Architecture and how a Lean Architecture approaches his responsibility.

Simplicity is a systemic quality in all levels of IT architecture. At Enterprise Architecture level, it helps create clarity on business functions, demands and responsibilities. Here it has a big impact on overall IT complexity and size. Thus it is a major driver in IT cost and business agility. Roger Sessions has done some excellent work in this area. At system and application level, simplicity is important to make sure systems can be easily coupled and integrated, but also in terms of changeability and maintenance. At software level simplicity is a key factor in comprehensibility, maintainability and the ability to find bugs or optimize the code.
 
Simplicity in IT architecture has many benefits. Simple systems are more comprehensible, easier to adjust and have lower maintenance cost. Because it is easier to find and understand the parts of the system that really matter.  But there are even more benefits, such as a better connection to business goals and functions and increased changeability of systems. It is also much easier to create a consistent IT infrastructure based on a simple architecture.

I think it is very strange that in many software quality systems, simplicity is hardly ever considered a systemic quality.  Sure, there are lots of systemic quality aspects related to it, such as understandability and analyzability. But in itself, we hardly see it recognized in quality systems. That is a shame. Simplicity must be a driving force and design goal in systems development and enterprise architecture. Simplicity has an enormous positive impact on cost, time to market and IT effectiveness and cannot be neglected.

A lot of effort is put into testing and verifying applications these days. A number of formal testing methodologies have been formulated. A Dutch product for instance is TMAP. Sure it makes sense to define how you wish to approach your testing. However, one of my major gripes with approaches like that is they are very formal. And in the case of TMAP it approaches software development as a staged, waterfall process. In this process the testing department is a divine institution, detached from reality, whose prime purpose is to uncover defects in the product of ‘the others’.

In my opinion this approach is exemplary for a lot of testing departments out there. They are missing the point, two points actually. The first is that they do not acknowledge that testing must be part of the overall QA effort in an organization, not an isolated activity. On any project and any organization that takes software development seriously, a vision on how to approach the matter of QA is necessary. Testing is just a part of this. Having and overall vision we can ensure the money allocated for QA is spent wisely.
The second missed point is that testing and QA can not and should not be detached from the development work. Doing so promotes a ‘we vs. them’ culture where there is no sense of common responsibility. Ever been on a project where the testing team was doing nine to five and the developers 24×7? Or even worse, I’ve seen projects where the testing team was sitting idle for months, waiting for something to test to come into their domain. What a waste!

Old school QA results in doing testing and QA detached from and after the actual creation process. All that can be done then is to discover and signal the flaws in the product. Which then need to be fixed. I call this reactive QA. There is no way QA can do anything substantial about a lack of quality, they just signal it. Others will then have to fix them. Adding another non-value adding creation stage.
The contribution of reactive QA to the overall success and quality is limited. No structural process improvement occurs as a result of it.

It would be much better if QA would be employed proactively. If QA was working in cooperation with development or production teams to improve the product. From a process perspective the role of proactive QA can be formulated as: “assisting the production and development team to improve the process while it is being executed”. QA must in this scenario take an active, participatory role. QA and testing in particular cannot afford to be standing on the side observing and commenting on what is produced. Now they share in the responsibility for creating a great product.

There are two very low level examples of proactive QA that people familiar with Agile and Extreme Programming are already familiar with. Pair programming and Test Driven Design. Pair Programming is a form of QA where the QA agent sits with the programmers and together they formulate the best solution of the issues at hand. No separate code review is necessary, since two pairs of eyes are already looking at the code as it is being written.

In Test Driven Development the application development is driven by pre-formulated and often automated test. The most prominent advantages here are the automated regression test are available even before the software has been shipped. Developers tend to pay more attention to the testability of their code and a better correlation with the functional and non-functional requirements to the code is hardly imaginable.

Another example of proactive QA that is not so much tied to software development is a Process Coach. At Xebia we have a number of people working with our clients as an agile coach. They help the client’s organization make the transition to working agile and to organize the people in agile teams. We have found that is of limited use and less effective to practice agile if the environment is not. Agile coaches help the people on the project to improve their way of working and their practices to become more agile and more effective.

In summary, proactive QA is a big change from conventional reactive QA. The role, competencies and responsibilities of QA people change dramatically. Implementing this can be challenging, since it requires a cultural change. The benefits are enormous. The involvement of QA in the actual creation and their contribution to in process improvement does really improve quality when it matters: before errors are made.

Obviously we as consultants have more goals than to make the assignment a success and to get the job done. We have our own careers and the future of Xebia that are also important to us. But that does not mean that while we on the job were are not giving our 100% to reach the clients objectives! On the contrary, I personally have worked in many companies where external people displayed a much bigger passion and drive for their work than the internal people who had being sitting there for many years. (those poor people, will they ever make it to retirement, or will their precious little jobs be reorganized away before that?)

Hiring externals is not a bad thing. There are many excellent reasons for getting in people from the outside. They (we) can bring expertise and experience that is not present in the organization. Consultants can fill up gaps and bring a fresh perspective, new knowledge etc. Having heterogeneous teams is a fact of life these days. Maybe in the early nineties it was still possible to have teams with only employees, nowadays the reality is that a lot op people like to work as a consultant and the labor market is so cramped up that you really need to bring in external staff to get the job done.

So how to deal with “us externals”? As I said before, having a team and sharing goals and visions is essential for effective cooperation. You need trust, confidence and respect. Being the lead architect of a company implies that you know who you teammates are, what they are capable of and most importantly that you can trust them. Real trust extends way beyond hoping that people hold their end of the bargain. It means relying on them, knowing that they will go beyond the agreed stuff that the will take responsibility for situations on which no agreements were made, but that do need action. That is who we are: we take action where we think it is needed for reaching our goals. So you better make sure that our goals are your goals. Make us part of the team!

succes
The success of the project is measured against its goals, its objectives. This is one reason why it is important to properly understand the project goals. How often don’t we see projects or people finish something, just to realize (or be confronted to) that they did not deliver what was demanded. It is like reaching the top of a mountain after a long, difficult and dangerous climb, only to realize it was the wrong mountain you climbing all along.

As stated earlier, the goals are ideally set before the start of the project. This implies that the goals have their origin, their base, outside of the project itself. This does not mean that the project cannot influence its goals. Experiences and insights gained on the project can make us see and understand the goals of the project differently.

Project goals are not fixed. The objectives for a project ought to be the result of careful deliberation and weighing pros and cons. If the paradigm on which a goal was based change, this might change the validity of that goal. Looking at reasons for changes of goals, I think there are two main sources of change: external conditions, the environment, and lessons learned within the project, the internals. These two sources are discussed below

external condition changes
During the course of a project, its environment is subject to change. These changes may be large or small and can have a big, minor of even no impact on the project. The arrival of a new competitor on the market might urge the organization to speed up the introduction of a new product, even at the expense of bigger investments. So this single event has impact on multiple goals of the project, time and money. More fundamentally it has had influence on the business case. If the new competitor would succeed in obtaining a substantial market share before the product would be released, it might become hard or next to impossible to get return on investment on the project. Thus, changes in the environment can lead to changes in the business case and to fundamental changes to project goals. In our previous example, while traveling from A to B, we might encounter a traffic jam and decide to take the alternative route to get to our destination.

internal lessons learned
When we run a project, we gain additional insight in the viability of the project goals. There is a plan that specifies what needs to be done when at what cost. However, we might learn that a chosen technology is not suitable for what is was selected for, of does not yield the productivity promised. Or we might find that communication between certain parties involved is so difficult, that more time is needed to come to mutual acceptable solution. Both of these findings have impact on the viability of the project goals. If the project needs to be done by a set date, but the involved parties can’t seem to reach an agreement until late, it is not likely that original deadlines can be met.
Or in our travel example, we might discover our car has gotten a flat tire which needs to be replaced before we can continue. This certainly has an impact on our itinerary.

We have seen that on a project there is a continual influence between the project plan, its goals, external changes and internal lessons learned. In most projects, even the prescriptive ones that are led in a deterministic way, the project plan changes as the project progresses. There is however a difference between accepting changes as a basic principle of project management and changing the plan only when forced to by the circumstances. The later approach is reactive, one that in essence sees change as bad and as something to be avoided. This often leads to suboptimal choices and in which circumstances are seen as things that need to be managed and are dealt with as risks. Alternatively circumstances can be seen as opportunities. If we accept change as a necessity to keep current with reality, we can actually use it to make sure we reach a reality based result. In the end, what really matters is getting there and adapting to change is part of that.

A plan should describe how to realize the business case on which the project is based. In the criterion based approach to project management this means that the intention of the project is described, but not all activities on how to materialize the business case are specified. The essence of the plan is to explain or to translate the business case into practical guidelines and criteria on how realize the business case. Put differently, it specifies the high level requirements for the project that need to be met for the project to be deemed successful. Tom and Kai Gilb for instance like to state that approximately 10 high level requirements should be enough to give direction to a project. These requirements then are the criteria used to measure the progress and success of the project.

the plan as a vision
In the criterion based approach the plan can be seen as a vision statement.
It is used to convey and clarify the vision of business case and it is used to create a shared vision within the project team. The project team will then be organized around that vision. This makes managing the project a lot easier. Instead of managing people based on their actions and activities, the project manager has to guard the vision. He has to make sure the project team has the correct understanding of the vision and is acting in accordance with it. Project members that have a good understanding of the essence of the business case are able to organize themselves and to choose for themselves the appropriate actions. They do not need to be managed, they can be led.

communication is bi-directional
If we support the notion that a plan is really a way to communicate the vision and direction of the project, we also need to asses how to do this most effectively. Change is part of that.
Communication is a two way thing, Especially on projects where people cooperate towards a shared goal.
Then as the project is executed data is being generated that must be fed back into the plan. The feasibility of the goals becomes clearer as actions towards achieving them are undertaken. Assumption that are part of the vision are being tested and evaluated by the project team. Whether the project team will be able to achieve certain goals can only be determined in reality and cannot be deferred from the plan. This information must then be fed back into the planning process and in the plan itself. Thereby improving the quality and reliability of the plan. If we wish our plans to be based on reality, we must allow feedback from that reality to form the basis of the evolving plan.

the plan as a status indicator
The plan should reflect the current status of the project. It should indicate what has been achieved thus far and what still needs to be done to reach the goals of the project. As times passes these things change. Progress is made and the feasibility of the unfinished work can be better assessed as time passes. Thus the project plan needs to be updated regularly to reflect the progress and the new insights. This also implies that really only the current status of the project plan is important. Yesterdays’ planning is no longer relevant today.
For the historians on the project it will be interesting to see how the plan changed over time, but for the “present-based” population, only the current version of the plan reflects the reality on which future action and direction needs to based.

Central to this discussion is the matter of the “purpose of a plan”. As a working definition I use: “A plan is intended to give guidance to the activities executed as part of a project”. This is a rather generic description of a plans’ purpose and is intended to be applicable to any kind of project management style. It is not the reason for making a plan that differentiates different project management styles, it is the intent of the plan and the way it is used to govern the project that is distinctive.

Many project management approaches use a plan to specify what actions need to be taken at what point in time and which deliverables are expected when. This is a prescriptive approach, which seeks to fix the steps and milestones of the project upfront. The appeal of this approach is that everyone knows upfront what to expect. For a manager it is very convenient, since he can manage against the plan and tell project team members what and when to deliver. Stick to the plan and you’ll be alright.

The alternative approach would be not to fix the deliverables, but to limit the plan to a project vision. This vision describes the goal of the project, the high level requirements that should be met and maybe some constraints on how the eventual solutions should be achieved. The project vision is then used during the project to guide decisions that need to be made. This is a criterion based approach.

Both of these approaches fulfill the need for the guidance a project plan is supposed to deliver. However, their implementation and applicability is very different. The prescriptive approach is useful when the activities that make up of the course of the project can indeed be predicted up front. This requires thorough knowledge of the project conditions, its problem domain and the optimal solution the project is expected to deliver. Furthermore effective management of the environment is of vital importance to prevent outside influences that might cause deviations from the project plan. The criterion based approach is useful in situations where there are a lot of uncertainties and no concrete solution can be defined up front. It requires that the people involved are able to continuously translate the project vision to the actual situation and to determine what actions contribute best to the optimal end solution. If the project members are not able to do this, this approach will not work.

In an environment that continually changes – and what environment does not – a plan should never be used as a rigid list of steps that needs to be executed. If this happens, the plan tends to become more important than the result it was intended to deliver. The criterion based approach admits that not everything can be predicted and controlled. This has consequences for the project plan and how it is used. As reality evolves, the plan should evolve with it. Where the project reality has a time aspect, so should the plan. Experience and lessons learned during the project should be integrated into the plan. Thus the plan keeps changing. Last months planning is not valid today, since today’s reality is not the same reality as the one last months planning was based upon.

As stated before, the purpose of a plan is to provide guidance. This can be accomplished in multiple ways. Different situations call for different approaches towards the plan. However, a plan should never become more important than the goal it was made for. A plan should be based on reality.

In a series of blog entries we will investigate the role of plans in a project management and try to find some answers on what the role of the plan should be, how the use of a plan affects the effectiveness of a project management approach and how it affects the way you deal with people.

As you can judge from the title, in my opinion one should not try to map the plan to the day to day reality of the project. Unexpected things will always occur and new insights will blossom. Project management must and should want to deal with that in the most constructive way, even if it was not part of the plan. The success of a project greatly depends on how one deals with unexpected events. Reality can be a real pain, especially if it does not stick to the plan.