Friday, December 30, 2005
Enterprise Architecture and Software Product Lines
Several years ago, the folks at the Software Engineering Institute came out with the notion of software product lines. We incorporated modern thinking based on their original work in our book, Practical Guide to Enterprise Architecture hoping that enterprise architects everywhere would start incorporating this form of thinking.
Software product lines offer tremendous potential to improve a company's competitive position and responsiveness to changing market needs. The transition from traditional software development where products are developed independently from one another to an approach that is based on multiple development groups working in a collaborative fashion to deliver products to market requires a massive change in how things are done. It requires the notion of business architecture. It also requires better thinking from executive row than simply throwing things over the wall to outsourcing firms who are only guaranteed to make a mess out of things.
For enterprise architects that have a strong sense of business planning and can articulate architecture in terms of financial constructs are better positioned than those who are solely technology focused. I believe that every architect should understand business. This doesn't mean that you have to indoctrinate yourself into the particular business of your company and the particular industry vertical but it does mean that you should understand business and finance 101.
The investment costs and risks, as well as the downstream benefits can be significant. Gaining executive stakeholder buy-in to making the investment requires a business case that translates the qualitative benefits of software product lines into something tangible. The business case process can be an effective decision
making tool for not only deciding whether an organization should transition to an SPL, but also how best to make the transition a success. Software product lines can become another aspect to strong IT governance.
Anyway, I implore every architect reading this blog entry, to check out the following sites/books:
| | View blog reactionsSoftware product lines offer tremendous potential to improve a company's competitive position and responsiveness to changing market needs. The transition from traditional software development where products are developed independently from one another to an approach that is based on multiple development groups working in a collaborative fashion to deliver products to market requires a massive change in how things are done. It requires the notion of business architecture. It also requires better thinking from executive row than simply throwing things over the wall to outsourcing firms who are only guaranteed to make a mess out of things.
For enterprise architects that have a strong sense of business planning and can articulate architecture in terms of financial constructs are better positioned than those who are solely technology focused. I believe that every architect should understand business. This doesn't mean that you have to indoctrinate yourself into the particular business of your company and the particular industry vertical but it does mean that you should understand business and finance 101.
The investment costs and risks, as well as the downstream benefits can be significant. Gaining executive stakeholder buy-in to making the investment requires a business case that translates the qualitative benefits of software product lines into something tangible. The business case process can be an effective decision
making tool for not only deciding whether an organization should transition to an SPL, but also how best to make the transition a success. Software product lines can become another aspect to strong IT governance.
Anyway, I implore every architect reading this blog entry, to check out the following sites/books:
- Software Product Lines
- Product Line Practices
- Software Product Lines: Practices and Patterns (Book)
- Designing Software Product Lines with UML (Book)
