A value stream for architects
"Great work! I really enjoyed the read." "Nice!" “Very useful”, “Fantastic article, concise and to the point.” “Really interesting, thanks for sharing your insights.” “Helpful overview on how EA fits in the big picture.” "I like this very much. Well done!”
A comprehensive architecture framework contains guidance on
This article focuses on the end-to-end process, or value stream.
People
The number of roles called “architect” varies widely between organizations. Some enterprises have never set up an EA practice; some have done so and struggled to make an impact. However, many do have a team called “strategy and architecture” or the like. Every enterprise has to work out for itself how its roles cover the cells of the table below.
Read the next article for more on how architecture roles are defined in standards such as the "Skills Framework for the Information Age" and TOGAF.
Products
The graphics above include the names of some products, This article focuses on the process.
Process
The architecture value stream proceeds naturally through four phases.
I have my own architecture process, but the best known is surely TOGAF, so let refer to that below. Despite its many flaws, much criticism of TOGAF is misplaced, and it does provide a reasonable basis for explaining work that architects may be engaged in ?
The ten phases of TOGAF’s Architecture Development Method (ADM), can be grouped below under the four headings above.
Initiation
Architects work with sponsors and stakeholders.
Architecting
Architects work with business analysts and technical speciialists to produce an architecture definition document covering:
Planning
Architects work with project managers to produce an architecture road map and plans for projects.
Governance
Architects monitor and steer the delivery and change of systems by carrying out compliance assessments in two more phases.
领英推荐
You may see phases A to F as a “big up front” design and planning process, but how much time and money you invest in each phase, and the level of detail produced, are scoping decisions made at the start, and revisited as need be.
Use of the process
Agility
TOGAF’s ADM is presented as sequence of phases A to H, but is used both incrementally and iteratively. The process starts with a request for work to ease some particular pain or pursue some vision or opportunity.
An enterprise may progress several ADM cycles in succession (to incrementally develop or change one function) and in parallel (to develop or change different functions).
You might well model the current (baseline) architecture before the required (target) architecture. However, TOGAF suggests that when looking to make a radical innovation, you start by modelling the target architecture, then iterate between baseline and target.
Within one cycle of the process, you may move back and forth between phases, iteratively revising or elaborating earlier decisions and products.
Levels
TOGAF’s process is based on the presumption of its authors that the same process can be applied at three levels of architecture, which they call Enterprise, Segment and Capability. This article presumes three levels of architecture that are a little different.
Enterprise architecture takes a cross-organizational and strategic view of such business activity systems. It works to integrate business system planning with business planning. Enterprise architects work at the business function/capability and application portfolio level.
Solution architecture is carried out at a narrower and more tactical level; often in relation to one particular system, or one business process that requires system integration. Solution architects typically identify the major use cases/epics that applications provide to their users. They shape and steer development projects, keep them on the rails and in step with more strategic cross-organizational thinking.
Given a list of use cases or epics, an application may be developed using agile methods and dev-ops techniques, provided there is some oversight from an architect with a view to the wider enterprise architecture.
Software architecture is needed for software development projects (agile or not) that emerge from application portfolio management and other high level architectural thinking. A software architect may elaborate a given solution architecture, complete the component structure and APIs of an application, and address the detailed design of messaging between applications or components.
Tailoring the process
The process produces different products at the enterprise level (such as road maps for applications) and solution level (such as solution outlines or SADs for projects).
There are two ways to adapt a generalized process
Specialize the activities of enterprise and solution architects. For example, TOGAF's ADM is a highly generalized management framework for “architecture projects” at any level. You must customize it for use by enterprise and by solutions architects.
Sequence the activities of enterprise and solution architecture. The graphic above shows a way to sequence them in one architecture framework - overlapping at the solution vision stage. It sequences enterprise and solution architect roles in a value stream that can be mapped to the process in TOGAF. It indicates where enterprise and solution architects play their roles in changing business activity systems.
Either way, for each situation or initiative you must select relevant processes and products from whatever generic framework you us.?
Integration with other processes
Remember, every enterprise must integrate the processes of an architecture framework with that organization's processes for:
The value stream above is not an organization structure, it says nothing about where Service Management sits, which should be close to business directors and managers.
Related articles
The graphic above, which includes a mapping to TOGAF, is a simplified version of the value stream in Avancier Methods, which are usually presented as a solution architecture framework, but do include portfolio analysis, and can be used by enterprise architects. This slide show elaborates the value stream into finer-grained activities.
This article is included with 12 others in “A Systems Thinker’s View of Enterprise Architecture”, a book made available to community-tier members of Cyb3rSyn Labs.? You can subscribe here: www.cyb3rsyn.com.
Can we say that Enterprise Architecture is about structuring the enterprise (incl. the relation with the environment) in order to envision possible future paths, while Solution Architecture is about realizing the envisioned future path?
Forget about ITIL or COBIT until you've learned to think the USM way. Reduce your organization's complexity for a sustainable Enterprise Service Management strategy. USM's revolution is ESM's evolution.
4 年Two sideline comments: 1- this is again focused on *change*, which is not the goal of the company. The company's first interest would be stability and continuity of what it *has*, not what might be. 2- if PMO is not included in (IT)SM, then whatever comes out of this, it will never work efficiently. PMO next to SM would imply two competing management systems, and that's exactly why there's such chaos around us. If every car would have two steering wheels, everyone would understand why that car won't do what you expect from it, but when it comes to managing organizations, this seems to be the standard.
President and Chief Data Officer at Logical Data Guy Consultants
5 年Can enterprise and solution architects use the same architecture framework? Of course they can, they are both doing requirements and solutions type activities. As I said earlier EA are doing it at the organization wide level and SA are doing it at the local level. (Hard to find the right words.) TOGAF promotes the notion of architectural cycles. So the enterprise architecting activities use TOGAF to manage the requirements and design elements of the organization wide design activities. Solution architecting activities would use TOGAF to manage the local efforts.
President and Chief Data Officer at Logical Data Guy Consultants
5 年In my view Enterprise and Solutions architecting are both directed to identifying requirements and developing solutions. The only difference is scope, EA focus on solutions across the various functional areas, while SA focuses on specific functional areas. A functional area includes organization and business activities structures.
President and Chief Data Officer at Logical Data Guy Consultants
5 年"An EA function takes a higher-level and cross-organizational view, looking to rationalize, standardize, integrate or update systems." Sounds like the EA function is doing solutions architecture at the organization wide level. The organization wide solutions would set the context or scope for local solutions. For example, the EA activity would identify the high level design for an Order to Cash value stream. That design would identify the involved business functions (order taking, fulfillment, accounting/settlement and delivery), as well as the end to end business and technology resources that would manage and execute the order to cash business processes. In my view part of the EA activity would include selecting and establishing the implementation roadmap for the technology solutions that would support order to cash. Once the overall design has been established the solution architecting activity would begin detailed design activities to realize the individual components of the high level design