A “Framework: is a meta-level (a higher level of abstraction) through which a range of concepts, models, techniques, methodologies can either be clarified and/or integrated. A framework is a static model.”

A “Methodology: is an explicit way of structuring one’s thinking and actions. Methodologies contain model(s) and reflect particular perspectives of ‘reality’ based on a set of philosophical paradigms. A methodology should tell us what steps to take, in what order and how to perform those steps but, most importantly, the reasons ‘why’ those steps should be taken, in particular order.”

Before we can really discuss architectural frameworks and methodologies, we need to really understand the difference between a framework and a methodology.

Another way to look at this: a framework is essentially a library with classifications and taxonomy that contains the “what” – the common set of elements, [e.g. knowledge bits and things: designs, implementations and parts, as well as tools] for a specific discipline or domain. The contents describe the variability in particular ways these elements can be combined, assembled and used. This content sets a frame for the specific work via. guidelines for supporting the various phases of the work, templates for capturing the requirements, modeling, design, test cases, etc. to achieve the required outcome of the work and tools to do the work.

A framework does not instruct one in “how” to do the work, or the actual method to get the work accomplished. Elements here meaning much like the periodic table of elements.

No framework or methodology is complete for each has its advantages and disadvantages. They are quite different from each other, both in goals and in approach not necessarily in intent or objective.

The function of a successful practicing architect and the architecture practice at large is to rationalize and set the appropriate framework and methodology for the practice, align it to the organization and measure its execution and adoption. In addition to this, other peers and peer organization do the same function for their disciples (e.g. the PMO with PMLC or Security with the SLC) and am architect is expect to interface with these other frameworks and methodology to essentially set up the Organizations ecosystem, for frameworks and methodologies do complement each other often blending together synergistically. The better the synergy the more value the ecosystem provides to the Organization and the easier it is on the workforce.

Multiple frameworks are used, and often roles are assigned to each framework within an organization. Typically you will need at least one planning framework, one project implementation one (for software and/or infrastructure) and one operations framework.

A methodology is a defined, structured set of processes, procedures and techniques on “how” to get the work accomplished within the frame of the decline or domain. Methodologies most often include a set of specific practices for diagramming notation and documenting the results of the procedure for communicating the work; systematic approach for carrying out the procedure for doing the work; and an objective quantified set of criteria for validating the work.

Enterprise Architecture Frameworks

• The Open Group Architecture Framework (TOGAF)
• Gartner EA Framework
• Federal Enterprise Architecture Framework (FEAF)
• The Zachman Framework for Enterprise Architectures
• Custom
• Augmented by “principles” and IT strategy (often cultural “golden rules”)
• Augmented by recharge and financial mechanisms

It is important for an architect to select the appropriate framework and apply the suitable methodology to accomplish their engagements successfully for the various products, services and internal organizations they serve. These frameworks and methodologies are core to their engagement model and allow the architect to achieve predictable and repeatable results. An architect needs to have breadth across the most common enterprise level frameworks.

The key here for the architect is to be able to navigate the range frameworks and methodologies across the various life cycles with their tool set and standards, understanding what is core to each and what it delivers to a successful engagement. An architect needs to have a root understating of how the various frameworks and methodologies are organized.  Based on the teaching philosophy of Ray W. Murphy

A framework is a taxonomy or structure with the essential elements. A methodology is a process that has input and output. So for a business entity:

Business Architecture and Strategy frameworks and methodologies provide the tools necessary for surfacing and capturing business goals, concerns, and drivers and develop a strategy to create an optimized IT environment with the greatest flexibility and value to the organization.
Enterprise-level frameworks and methodologies provide the tools necessary for managing the entire IT environment across the organization and provide a portfolio and program view. These tools and methodologies also provide the traceability tools needed to create business requirements that provide an optimized IT environment with the greatest flexibility and value to the organization.

Project-level frameworks and methodologies provide the tools necessary for managing the IT environment at a project level and provide an LOB view across the system development life cycle (SDLC). These tools and methodologies also provide the traceability tools needed to create business requirements that provide an optimized IT environment with the greatest flexibility and value to the organization.

Operational-level frameworks and methodologies provide the tools necessary for operating and maintaining the entire IT environment across the organization and provide an enterprise and LOB view of performance and value.

Patterns and anti-patterns are available for all levels of framework and methodology and provide examples of approaches that work and that do not work.
Maturity models are available for all levels of framework and methodology and provide too to measure and mature the level of ability and agility.

The Federal Enterprise Architecture Framework (FEA [or FEAF]) provide “…a common language and framework to describe and analyze IT investments, enhance collaboration and, ultimately, transform the [U.S.] Federal government into a citizen-centered, results-oriented, and market-based organization as set forth in the President’s Management Agenda.”

The Open Group Architecture Framework (TOGAF) is a set of models and tools for developing a broad range of IT architectures. Rather than prescribing a specific set of enterprise architecture deliverables or views, TOGAF is designed to be used with whichever deliverables are considered most appropriate for a given solution. TOGAF describes an example taxonomy of the views an architect might consider, providing guidelines for making that choice.

The Zachman Enterprise Application Framework (EAF) is a “logical structure for classifying and organizing the descriptive representations of an enterprise that are significant to the management of the enterprise as well as to the development of the enterprise’s systems.”

SDLC Frameworks and Methods

• Agile
• Scrum
• Extreme (XP)
• Rational Unified Process (RUP)
• Microsoft Solutions Framework (MSF)
• Model Driven (MDA, MDD)
• Rapid Prototyping
• Spiral, Waterfall
• Top-Down, Bottom-up

Different methodologies achieve different goals.

System Development Life Cycle (SDLC):

• Spiral has found success in the development of large systems but depends heavily on the ability to assess risks during development and the ability to eliminate or control exogenous influences. The risk analysis precedes each phase making this model and fast feedback loops promote better refinement at earlier stages, and are most useful when used for larger projects, especially when there are many “unknowns”.
• Waterfall is a sequential design process, often used in project management and software development processes, in which progress is seen as flowing steadily and systematically downwards through the phases of conception, initiation → analysis → design → construction → testing → implementation → maintenance. Changes of scope can reverse the flow between the phases, for example, a design issue can cause the project to move back to analysis then begin the standard flow design → analysis → design causing a localized analysis iteration.
• Agile is a cyclical process, iteration based, where each iteration is like a miniature waterfall process software project including all of the tasks (or phases) necessary to release the mini-increment of new functionality, i.e. planning, requirements analysis, design, coding/engineering, testing, documentation, releasing. While not always the case, an agile methodology used for a software project intends to be capable of releasing new software at the end of each iteration. At this time, the team always reevaluates project priorities. Agile methods emphasize real time communication – preferably face-to-face – instead of written documents. Most agile teams are co-located during the entire software development/engineering life cycle.
• Extreme Programming (XP) is a lightweight process – you only do what you need to do to create value for the customer. It is a methodology based on addressing constraints in software development that adapts to vague or rapidly changing requirements. It does not address project portfolio management, financial justification of projects, operations, marketing, or sales.
• ISO/IEC 12207 describes the major component processes of a complete software life cycle, their interfaces with one another, and the high-level relations that govern their interactions.
• Microsoft Solutions Framework (MSF) is an adaptable approach for delivering technology solutions successfully, faster, with fewer people, less risk, and with higher quality. It does this by helping teams directly address the most common causes of technology project failure –improving success rates, solution quality, and business impact.
• Scrum defines a project management framework in which development activities of requirements gathering, design and programming take place. The development period typically a two-week to one-month iteration called a Sprint. The framework has three components: pre-sprint, sprint, and post-sprint. The focal point is the iteration Sprint, in which working software gets developed.
• Test-Driven Development (TDD) is about aiding the programmer and customer during the development process with unambiguous requirements. The requirements are expressed in the form of tests, which are a support mechanism (e.g., scaffolding) that stands firmly under the participants as they undertake the hazards of software development.

Determining the appropriate framework/methodology for your project management and solution development is a balancing act between finite current needs and infinite future needs. Specifically, choosing the right framework and methodology requires facing the need to striking the right balance between the agility of individual teams and providing enough process to support cross-team collaboration. The more prescriptive process-intensive methodologies add overhead in the form of process and documentation that may prove useful for the future needs of ongoing collaboration and the layering on of new requirements.

Other factors that can provide the solutions architect with guidance in selecting a methodology include:

• Project Team Size, larger projects are less suitable for agile methodologies. To apply an agile methodology to a project that requires tens or hundreds of developers may require breaking the project up into smaller pieces.
• Application Complexity, greater complexity often mandates methodologies that are more prescriptive.
• Experience and Skillset of the Team, More experienced teams are often more effective with empirical methodologies. This also relates to team size and complexity. Larger teams can have members with more in-depth specialize skillsets whereas smaller teams require members who have diverse skillsets. A major key to note here when the team or project is small it does not mean that team or project does not need all the skill and knowledge depths of a larger team or project; complexity is on the rise and it is taking greater skill to tame.
• Mandated Requirements, industry or vertical requirements as well as regulatory and compliancy, for example, solutions developed for the pharmaceutical industry typically require more process and documentation.

Reference Resources:

http://systemsphd.wordpress.com/2009/11/18/difference-between-framework-and-methodology/

Ray W. Murphy, Professor Emeritus, Engineering, Gonzaga University / Seattle University
http://msdn.microsoft.com/en-us/library/bb466232.aspx

See: http://www.whitehouse.gov/omb/assets/fea_doc/FEA_CRM_v23_Final_Oct_2007_Revised.pdf.

Sessions, Roger. “Comparison of the Top Four Enterprise Architecture Methodologies” whitepaper, http://www.objectwatch.com/whitepapers/4EAComparison.pdf.

The Gartner EA Framework provides both an EA Framework and an EA Process Model.
See: http://www.gartner.com/DisplayDocument?doc_cd=133132

Zachman, J.A. “A framework for information systems architecture,” IBM Systems Journal, 26 3, 1987, http://www.research.ibm.com/journal/sj/263/ibmsj2603E.pdf

Bijay K. Jayaswal, Peter C. Patton, “Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software”, Prentice Hall, 2007

See: http://en.wikipedia.org/wiki/Waterfall_model

Mike Turner, “Microsoft® Solutions Framework Essentials: Building Successful Technology Solutions”, Microsoft Press, 2006

Jim Highsmith, “Agile Software Development Ecosystems”, Addison Wesley Professional, 2002

Beck, Kent, “Test-Driven Development By Example”, Addison Wesley Professional, 2002, and Newkirk, Vorontsov, “Test-Driven Development in Microsoft® .NET”, Microsoft Press, 2004

Training:

Certifications: