Chapter 5 "Technology in-licensing"
This chapter talks about how different technologies can be integrated into a software architecture by licensing. A general point is that using code or components by licensing can save the energy and time of the key technical employees. On the other hand, it is important to have lawyers to clarify the relevant issues when licenses are involved.
There are many risks/rewards for using licensed technologies. One should keep all these in mind when being at the front of such decisions. Actually this is not only about component-based software. An OS can be a licensed technology to an enterprise. Such considerations of risks/rewards still apply here.
Another thing to be careful with is the software itself may have a different pricing model that conflicts with the licensed technologies. Here the software architecture matters. It should be designed to solve the conflict.
Open source technology is always a good consideration, but one has to bear in mind the pros and cons behind it. Every open source software license is different.
Showing posts with label Beyond Software Architecture. Show all posts
Showing posts with label Beyond Software Architecture. Show all posts
Tuesday, September 9, 2008
Tuesday, June 17, 2008
Notes for Chp. 4 of "Beyond Software Architecture"
Chapter 4. Business and License Model Symbiosis
Software vendors normally have one or more license models on each of their products.Why do we need a license? Because software is different from solid objects. You cannot stop people from copying it, redistribute it, and even reverse-engineering it. License is a legal way of protecting people from abusing the product while still enjoying not only the product but also the services around the product.
There are several common software business models. For example, users can by access or use of application for a period of time, or they can be charged at a percentage of their cost saved from using the software (enterprises tend to be resistant to this model), or they can be charged per transaction, or the vendors can be more precise by metering the users accesses on different resources(for example, the amount of concurrent users). Users can also be charged on the hardware that runs on the software instead of the software itself. Another way is used by the open source tool vendors.An open source tool is free. But if you want specialized services on top of the tool, it comes with price.
I have two reflections on the pricing models.
First, modern software tends to provide more features with online access. One example being the anti-virus software which normally needs to updates its virus library regularly. By using the Internet,one can find certain ways of protecting the software from abuse. In fact, in the architecture design process, one must try to include this business model in the technical design.
Second, software vendors must think of their architecture to have specialized support of more precise pricing models, such as the metering. Not all software can be priced by the metering way. But it is preferred by some customers.
There can be different rights and restrictions (most of them are very technical) associated with each type of business models. Again, the tarchitecture is very important in embedding such rights and restrictions in the technical design.
So, how can tarchitecture help the business model? I am sure that may technical architects have quite a lot of ideas in their mind. There are following things that one should always be careful with.
1. The most important thing is to capture the necessary data for the business pricing. This has to happen within the architecture.
2. Give the necessary report so that both the vendors and customers can be aware of the details of the cost.
3. Put something there to enforce the business model in case the license is violated.
4. Sometimes, the price can also be linked with those "-ility" such as scalability and reliability. The architecture should be able to support it.
5. Successful tarchitecture must also try to help customers to save their budget on other things such as the hardware investment.
6. Vendors should regularly adjust the parameters used in the pricing models. Everything changes over the time,especially in the IT world.
There are many ways of enforcing the licensing models. One can always try to link the architecture with online access to ensure that people are serious when using and paying the software. However,up to now, I have not heard any 100 percent secure licensing model if there is no law to protect the copyright of software.
Finishing on the tarchitecture, let us get back to the marchitecture. In fact, in the beginning of specific software market, vendors can make the business models very simple so that customers can easily understand and decide to buy. The idea is of course to occupy the market first.
The maturity of the market decides on the business model, indeed.
Software vendors normally have one or more license models on each of their products.Why do we need a license? Because software is different from solid objects. You cannot stop people from copying it, redistribute it, and even reverse-engineering it. License is a legal way of protecting people from abusing the product while still enjoying not only the product but also the services around the product.
There are several common software business models. For example, users can by access or use of application for a period of time, or they can be charged at a percentage of their cost saved from using the software (enterprises tend to be resistant to this model), or they can be charged per transaction, or the vendors can be more precise by metering the users accesses on different resources(for example, the amount of concurrent users). Users can also be charged on the hardware that runs on the software instead of the software itself. Another way is used by the open source tool vendors.An open source tool is free. But if you want specialized services on top of the tool, it comes with price.
I have two reflections on the pricing models.
First, modern software tends to provide more features with online access. One example being the anti-virus software which normally needs to updates its virus library regularly. By using the Internet,one can find certain ways of protecting the software from abuse. In fact, in the architecture design process, one must try to include this business model in the technical design.
Second, software vendors must think of their architecture to have specialized support of more precise pricing models, such as the metering. Not all software can be priced by the metering way. But it is preferred by some customers.
There can be different rights and restrictions (most of them are very technical) associated with each type of business models. Again, the tarchitecture is very important in embedding such rights and restrictions in the technical design.
So, how can tarchitecture help the business model? I am sure that may technical architects have quite a lot of ideas in their mind. There are following things that one should always be careful with.
1. The most important thing is to capture the necessary data for the business pricing. This has to happen within the architecture.
2. Give the necessary report so that both the vendors and customers can be aware of the details of the cost.
3. Put something there to enforce the business model in case the license is violated.
4. Sometimes, the price can also be linked with those "-ility" such as scalability and reliability. The architecture should be able to support it.
5. Successful tarchitecture must also try to help customers to save their budget on other things such as the hardware investment.
6. Vendors should regularly adjust the parameters used in the pricing models. Everything changes over the time,especially in the IT world.
There are many ways of enforcing the licensing models. One can always try to link the architecture with online access to ensure that people are serious when using and paying the software. However,up to now, I have not heard any 100 percent secure licensing model if there is no law to protect the copyright of software.
Finishing on the tarchitecture, let us get back to the marchitecture. In fact, in the beginning of specific software market, vendors can make the business models very simple so that customers can easily understand and decide to buy. The idea is of course to occupy the market first.
The maturity of the market decides on the business model, indeed.
Sunday, March 16, 2008
Note of Ch. 1 for "Beyond Software Architecture"
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.
"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.
Notes for reading "Beyond Software Architecture"
This is a wonderful book by Luke Hohmann.
I read some chapters ayear ago and used them as foundations for several of my lecturesin Aalborg university. Having been in industry for 6 months, Ijust found out that it is very beneficial to read the book againand write down notes based on my past and current experiences.
So,let us just start.
I read some chapters ayear ago and used them as foundations for several of my lecturesin Aalborg university. Having been in industry for 6 months, Ijust found out that it is very beneficial to read the book againand write down notes based on my past and current experiences.
So,let us just start.
Subscribe to:
Posts (Atom)