MSF: Microsoft Source of Fame
There are bunches of buzzed words running around Microsoft world but certainly, people (at least in Microsoft) tend to talk more and more about something called MSF (Microsoft Solution Framework), which clearly indicates growing concerns over software development process within the giant software vendor. Microsoft is making steep climb on enterprise software solution and integration. Having the opportunity to attend a discussion/interview with one of Microsoft Asia Pacific’s senior architects, I realized a big opportunity to shake hands with Microsoft (other than just Sun/IBM Java/EJB) in the coming years for that market.
With MSF, Microsoft starts to expose the software development process that is used in developing Windows and all other famous products such as Microsoft Office, Microsoft SQL Server, SharePoint Portal Server, etc.. However, with the recent dot Net big-bang, MSF becomes a more interesting topic for all other parties, particularly, those provide software development services and SI (Software Integration) based on Microsoft platform.
In this short writing, I would like to introduce some basic concepts of MSF as a brief reference for possible future implementation within some specific projects in FPT Software, whose process is mainly inspired from RUP (Rational Unified Process). Thus, it will elaborate only the core (foundation) of MSF, suggesting you to consider it an alternative to RUP although both are dedicated to iterative software development. Those who are not familiar with RUP can think of it a general framework to describe specific software development processes developed by the Rational Company, which is now owned by IBM Software. RUP is heavily based on its own defined “phases, core workflow, workers and activities, artifacts, tools, templates and guidelines”.
Definition
There are quite a few lengthy definitions about MSF written by both Microsoft employed and non-Microsoft employed authors, but I prefer the quite old definition dated back in 1994 that says MSF is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft.
After 10 years, this “solution based on experience” of Microsoft is stable and knowledgeable enough to be given a well-thought by all strategic architects of every IT organization. In its first introduction in 1994, MSF was just a loose collection of best practices from Microsoft’s product development efforts and Microsoft Consulting Services engagements. Since then, MSF has been evolving based on deliberate learning from the successful, real-world best practices of Microsoft product groups, Microsoft Services, Microsoft’s internal Operations and Technology Group (OTG), Microsoft partners, and customers. MSF uses this pool of real-world best practices, which have been proved both internally and externally, and simplifies, consolidates, and verifies them for easier understanding and adoption by partners and customers. MSF consists of 6 components:
- MSF foundational principles: The core principles upon which the framework is based. They express values and standards that are common to all elements of the framework.
- MSF models: Schematic descriptions or “mental maps” of the organization of project teams and processes (Team Model and Process Model—two of the major defining components of the framework).
- MSF disciplines: Areas of practice using a specific set of methods, terms, and approaches (Project Management, Risk Management, and Readiness Management—the other major defining components of the framework).
- MSF key concepts: Ideas that support MSF principles and disciplines and are displayed through specific proven practices.
- MSF proven practices: Practices that have been proven effective in technology projects under a variety of real-world conditions.
- MSF recommendations: Optional but suggested practices and guidelines in the application of the models and discipline.
In the remainder of this article, I will focus on the foundational principles that MSF is grounded from and compare them with RUP.
Foundational principles
MSF is heavily constructed from 8 fundamental bricks:
- Foster open communication
Technology projects and solutions are built and delivered by human activity. Each person on a project brings his or her own talents, abilities, and perspective to the team. In order to maximize members’ individual effectiveness and optimize efficiencies in the work, information has to be readily available and actively shared. MSF is against the need-to-know basis type of communication in favour of free flow information. To support the same idea, RUP facilitates open communication by having clearly-defined “workers” attached to the defined “activities”, allowing information to flow seamlessly
- Work toward a shared vision
MSF states that a shared vision for project is fundamental to the work of the team. The process of creating a project’s shared vision helps to clarify goals, and to bring conflicts and mistaken assumptions to light in all stages. Shared vision agreed by all parties will motivate teams and help to ensure that all efforts are aligned in service of the project successful end. Similarly in RUP, there is an artifact called “Vision document” that is made early in project’s inception by system analyst, providing fundamental answers to "why's and what's" related to the project. It is also a gauge against which all future decisions should be validated.
- Empower team members
This is a very basic and important principle that I prefer to RUP. RUP-style model still serves us very well in deed by having a set of activities and guidelines for staffing and teamwork, in which team members are selected per phases in a rather hierarchical structure and encouraged to focus on their particular activities only. In light of my experience, this principle of MSF provides a more practical approach to project development nowadays. MSF organizes project team as a “team of peers”, where empowered team members hold themselves and each other accountable to the goals and deliverables of the project. This can be seen in creating and managing project schedule activities. In MSF, schedule is encouraged to be made bottom-up, i.e. people doing the work make commitments as to when it will be done. This schedule will be supported by the whole team. Moreover, team members will be confident enough to report any delays as soon as they are perceived. Thus, team leaders are set free to play a more facilitative role, offering guidance and assistance when the project is most critical. As a result, the progress monitor is dissimilated across the team and becomes a supportive rather than a policing activity.
- Establish clear accountability and shared responsibility
MSF establish a set of team roles, where each role (e.g. User Experience role, Product Management role) represents a unique perspective on project. In the same time, the responsibility is shared among all roles as team of peers because any team member has the potential to cause a project failure. In RUP, the responsibility is clearly achieved by organizing roles, again, per phases. The whole RUP idea is about who will be qualified and selected to do the job in each phases. For example, in inception phase, analysts (representing business process analyst, business designer, system analyst, use-case specifier and even user interface designer) will be main players. Idea of sharing responsibility among team of peers is hardly supported by RUP.
- Focus on delivering business value
MSF considers a solution does not provide business value until it is deployed in production and used effectively. Thus, MSF drive the development process to a spiral (iterative model) where each round includes both development and deployment into production, thereby ensuring realization of business value.
RUP does not state out this quite clearly as MSF does but it does provide a strong support for iteration where a solution consists of many software life cycles. When reaching to the end of each software development life cycle, a certain business value is verified and delivered.
- Stay agile, expect change
MSF confirms that the existence of changes should be always expected and none of solution delivery projects could be isolated from changes. Furthermore, software team should expect changes from all stakeholders (e.g. customer) and especially within the team. A very nice new American English word I learnt from this is “chaordic”, which is made of the 2 words Chaos and Orders, indicating precisely the nature of any software project. RUP defines the mechanism for this through requirement change management where it expects to involve “extended team” (stakeholders, customer representatives, domain experts, and others). However, there is no fundamental assumption in RUP that changes will continually come as in MSF.
- Invest in quality
As in RUP, all investment in quality becomes investment in people, as well as in tool and process. However besides intensive quality encouragement during all stages of development, MSF puts a great emphasis on training people by creation of a learning environment, to expect every dime invested will returns a higher quality of the product/solution. Training time taken out from productive work hours, class funding and even consultancy service are all relevant.
- Learn from all experiences
Lessons and best practices are reviewed and possibly adopted at each milestones of the project life cycle. MSF emphasizes the importance of organizational- or enterprise-level learning from project outcomes by recommending externally facilitated project postmortems that document not only the success of the project, but also the characteristics of the team and process that contributed to its success. When lessons learned from multiple projects are shared within an environment of open communication, interactions between team members take on a forward, problem-solving outlook rather than one that is intrinsically backward and blaming. In RUP, experiences and best practices are facilitated by a wide range set of tools. RUP tends to focus on the interaction between “Tools” and “practices” where it expects the outcome for “configurable process”.
Now, you might find a number of similarities between MSF and RUP. In theory, I feel they are the same in meaning and different in wording. However, in practice, the implementation of each approach is a bit different in identifying focuses for each stage, each area. I, particularly, like the “team of peers” idea, where all members actively contribute their precious values to the projects. Each member can be a star, who should be lightened in the dark night curtain made by all others rather than under sun lights of the Mother of Nature. People, who love MSF, say it is Microsoft Source of Fame while those, who hate it, say Microsoft Source of Fools. What about you?
For more information on MSF, please visit:
Không có nhận xét nào:
Đăng nhận xét