Chapter 1 [Software Architecture]
"The foundation of a winning solution lies in the architecture that creates and sustains it."
First topic, how to define software architecture
From my own point of view, software architecture, or system architecture, is about the "big picture" of the system. If we just talk about software system, this big picture includes all non-trivial modules (or, functionalities), processes, data, user interfaces (if necessary), and the relationship among these elements.
Apparently software architecture can be described in multiple levels, depending on the level of details required. It is just like observing a picture. When standing from far away, you can just have an approximate view and things become clearer andclearer when you get closer. However, there is always a time to say 'stop' when you find out that, if moving even closer, you will lose some parts of the picture. Fortunately, there are many people that can work on one architecture.
That means, someone will have the overview and someone only needs to read part of the picture.That's the way software team works.
Second topic, what is also important and related to software architecture.
Software architecture is not always a purely technical issue. It is often influenced by 'people' and 'business' around the big picture. For example, when decomposing a big system into sub-s,sometimes it is necessary to consider how easy it is to manage the dependencies among the developing teams, if each team is in charge of one or a few sub-s. If there are sub systems A and B, and there are teams T1 and T2. It is much better to let T1(or, T2) to work only on A and the other team to work on B than to let A to work on parts of T1 and T2 and ask B to finished the rest of T1 and T2.
It is also important to design sub-systems by "putting different things into different groups." The problem is then how many groups we can find and perhaps predefine. It is a matter of experience.
An experienced architect may have the advantage of knowing all the necessary pieces that should be put into the architecture picture.Completeness is an important criteria for the success of an architecture.
Being an architect, it is important to know when and how to 'give in.' Being at an IT organization, one can often feel that it is difficult to agree with your teammates on the architecture picture. What is important then is to make design decisions solely based on the needs from customers and always try to keep an objective understanding of the needs. And, be ready to change the design when the customers change their needs (of course, if we follow CMMI procedures, this means a lot of change management procedures).
Is an architecture good or bad? Normally you cannot have a consistent answer if you change the target people and the time to ask this question. In case you really get an consistent answer,that means, the architecture is indeed a master piece (and I personally do not believe in any existing masterpieces).
Third topic, why software architecture is important
Normally a good architecture is an important key to the long term success of a system or a solution.
Architecture influences success in many ways.
1. Longevity. Normally architecture stays longer than the team that develop it. The time a developer is active on the same system can be 2-4 years. But the time a system can stay is over 10-12years.
2. Stability. A stable architecture means that minimal amount of fundamental re-work is necessary. If a system's functionality is extended by regular release life cycles, all the necessary changes(or, refactoring) and improvement is kept being added to the system. The cost of change will be minimized.
3. Nature of change. In principle, if a change will improve customer satisfaction or bring new features that can attract new customers, it is a good change. It is also a good idea to design at least parts of the architecture in a way that it is able to accommodate changes very easily. Such a design is like the 'plug-in-play' feature of current OS systems.
4. Profitability. The profitability of an architecture is often related more to the business rather than the architecture itself.But for the long run, simple and elegant architecture is the best 'return on investment' choice for any system.
5. Social structure. A good architecture works for the team that creates and maintains it. On the other hand, architecture also influences the structure, relation, and formation of the team.
6. Boundaries Defined. It is very important that people understand and agree on what is the new things. Boundaries questions are inevitable. What is important is that these boundary are thoroughly analyzed, documented, and managed (through a comprehensive configuration management method).
7. Sustainable, Unfair Advantage. A good architecture must have sophisticated, sustainable advantages so that it is very difficult for other competitors to duplicate. Even this is impossible to achieve, the architecture should be designed so that it provides deep advantage for other ways (e.g., many commercial ways) of competing. Normally, usability and performance are the two inevitable features of any new architecture.
8. About replacing an old architecture with a new one. Apparently it is a very difficult management decision to totally replace an old architecture with a brand new one. There are a few things to seriously consider.
i. If you can split half of your current team and do the re-platforming in approx. 1 year, then it make sense to do it. ii. It is very natural that the team on the old architecture must have certain amount of change. Maybe you do not need all the people of the old platform (maybe they are not willingly to learn new things or they are not capable of), but one or two trusted veterans of its development to make certain that the new system is faithfully implementing the functionality of the old. There will be skeletons, and you're going to need these veterans to know where these skeletons are buried. iii. It is of course that the re-build of the architecture should 'be careful' and 'may take longer time than expected.' Economically, a good rule of thumb is that it costs at least 20 percent of the total investment in the old architecture to create a functionally equivalent new one if you are using experienced people, with no interruptions, and a radically improved development process.
Fourth topic, what happens in the beginning of creating a new architecture.
Normally it starts from sketches on white boards or papers. The immature picture is going to be changed by a honest process where the architecture team discusses with all aspects and make necessary changes according to the feedback.
Sometimes people say that, once having an architecture picture,you need to explore the alternatives. This is 'virtually useless.' There are three reasons.
1. You may not have the time or budget to allow you to 'explore the alternatives.'
2. The nature of the problem is already limiting the amount of alternative choices. Sometimes it makes sense to explore the alternatives solutions for a specific detail part of the architecture if the alternatives do have radical differences.
3. Even you have the chances to look at the alternative choices, do you exactly know what is 'good' or 'bad' in all the pictures? It takes years to establish an architecture and only after putting the system running for certain amount of years can you really understand if it is a 'good' choice.Sometimes it is very necessary to kill a project if you can spot serious problems which lead to economical disasters to a system.
Fifth topic, patterns
There are not a few works that seriously document architectural patterns. Sometimes the patterns that decide an architecture is bad is more useful than the ones that tell you exactly what to do.Patterns are not believes, but just what 'they' did before. Anyone can choose to start a new 'pattern' and try to be successful.
Sixth topic, about re-factoring, care and feed of architecture
There are many occasions that, the project team has to deliver the product in a tight schedule so that parts of the architecture is done in an "ugly" way. Then, the team must pre-schedule a "re-factoring" phase to improve the "ugly" implementation after the initial work is delivered.
Another message is that it is very important that the feature and capability of a solution should be managed.
An architecture is somewhat like a garden. You have to keep taking care of it from time to time. Otherwise, it is going to be ugly after a while.
Seventh topic, a few architectural principles
It is a nature for most developers and architects that, when designing the architectures, they try their best to explore all the alternative architecture designs and give best shot after a decent and profound consideration process. The following principles seems to be the best ones from most of the time.
1. Encapsulation. This is a very well-known design. The basic idea is to group different functionalities into different "black boxes" (should I call it components?) so that the whole architecture is just like these boxes plus the communications among the boxes.
2. Interface. It is very important that the interfaces among different components are documented clearly and well.
3. Loose coupling. It means the interconnectedness among different components should be reduced to minimal. This will ease the changes and also improve the architecture if parallelism is used in the architecture design.
4. Appropriate granularity. The architecture design cannot be at the very very detail. When it comes to finer granularity, it means the freedom that the developer can take is more reduced which brings more difficulty to the implementation.
5. High cohesion. It describes the pieces in each component of an architecture. If all the elements are strongly related and contributed to a single task, the component is highly cohesive.
6. Parametrization. This is also related to components. Every component must define clear input and output.
7. Deferral. In many architecture design process, it is due to the business requirement that many design choices must be made ahead of time. This, of course, brings risk to the architecture and the solution. In general, it is always a good choice to try best to defer such choice-making process until you are very well prepared.
Eighth topic, how to let people understand the big picture
Apparently, not all the people in a development team can easily understand the picture you draw. This is because they have different roles, backgrounds, and knowledge. The best way is that you prepare different pictures for different people to understand and you make sure that these pictures are consistent. A very well-known method is the rational "4+1" model. There are four views of an architecture.
i. Logical view. This is more or less a static snapshot of all the components of a system. This view is focused on functionality.
ii. Process view. If the product is just a software, this view is about the concurrent processes. If the product is a kind of combination of software and services, this view includes a lot of business processes and the underlying IT processes that enable the business processes.
iii. Development view. It is a static presentation of organizations of the functionalities of the architecture.
iv. Physical view. This is a more "physical" picture of the architecture (it includes the physical technology maps).
One more thing, the "+1" is all about use cases. You can add as many use cases as necessary to
Ninth topic, about the architecture team
The team is very well connected to the architecture. This type of connection is by nature. One thing to remember is that, when in a large project, the initial team that creates the architecture has the biggest freedom to have choices and the latter teams do not.
No comments:
Post a Comment