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
- 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
- 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.