lunes, 28 de diciembre de 2015
sábado, 19 de diciembre de 2015
viernes, 18 de diciembre de 2015
miércoles, 16 de diciembre de 2015
Move from disconnection to alignment using business architecture to enable your strategic enterprise-wide initiatives.
jueves, 10 de diciembre de 2015
miércoles, 9 de diciembre de 2015
martes, 1 de diciembre de 2015
viernes, 27 de noviembre de 2015
jueves, 26 de noviembre de 2015
lunes, 23 de noviembre de 2015
DevOps: rompiendo las barreras entre desarrollo y operaciones bajo el marco de la agilidad, la ISO 20000 y la ISO 15504/12207
miércoles, 11 de noviembre de 2015
martes, 10 de noviembre de 2015
domingo, 18 de octubre de 2015
miércoles, 14 de octubre de 2015
martes, 13 de octubre de 2015
viernes, 2 de octubre de 2015
jueves, 24 de septiembre de 2015
martes, 22 de septiembre de 2015
lunes, 21 de septiembre de 2015
jueves, 10 de septiembre de 2015
lunes, 7 de septiembre de 2015
lunes, 31 de agosto de 2015
lunes, 24 de agosto de 2015
viernes, 31 de julio de 2015
martes, 28 de julio de 2015
HOW TO BUILD AN EA ROADMAP: 4 STYLES TO CONSIDER
lunes, 27 de julio de 2015
Applying COBIT in a Government Organizationhttp://www.isaca.org/COBIT/focus/Pages/applying-cobit-in-a-government-organization.aspx?cid=edmi_1108854&appeal=edmi?cid=edmi_1108855&appeal=edmi
5 Common Mistakes in Adopting COBIT 5
Bahrain Government Embraces COBIT 5 Governance and IT Management
Are You a COBIT 5 Expert, Champion or Consultant? Be Aware!
COBIT 5 and ITIL Adaptation at a Saudi Municipality
Lessons Learned From the COBIT Conference
State and Impact of GEIT in Organizations: Key Findings of an International Study
Using Versus Implementing COBIT 5
martes, 21 de julio de 2015
lunes, 13 de julio de 2015
lunes, 6 de julio de 2015
Business Transformation Management Methodology (BTM2)
lunes, 22 de junio de 2015
Business Transformation Typeshttp://www.cxo-transform.com/business-transformation-types/
What is The Business Transformation Management Methodology?
What is Business Transformation?
martes, 16 de junio de 2015
jueves, 28 de mayo de 2015
miércoles, 27 de mayo de 2015
martes, 26 de mayo de 2015
sábado, 23 de mayo de 2015
viernes, 22 de mayo de 2015
miércoles, 20 de mayo de 2015
viernes, 15 de mayo de 2015
jueves, 14 de mayo de 2015
Business Architecture Certification
The Business Architecture Guild will offer a certification which will further the advancement of the business architecture profession by providing a way to measure and document the knowledge and skills necessary to be recognized as a competent practitioner. Certification also helps organizations define job descriptions, assess job candidates and employee performance, and structure programs that enable business architecture professionals to enhance their knowledge and skills.
Certification holders will be able to obtain recognized competency in business architecture from the Business Architecture Guild that demonstrates their qualifications to engage in and practice the profession. Certification will cover the following practice and disciplinary domains.
1. Business Architecture Foundational Concepts: The section assesses basic understanding of general business architecture concepts, core versus extended business mapping disciplines, scenario use and context, and overall value proposition.
2. Business Architecture Core Mapping Knowledge: Core mapping disciplines test one’s knowledge of creating and using capability, value, organization and information maps and the interaction among these disciplines.
3. Business Architecture Extended Mapping Knowledge: The extended mapping disciplines section examines one’s knowledge of strategy mapping, stakeholder mapping, initiative mapping, product and service mapping, and policy mapping.
4. Business Architecture Alignment with Related Business Disciplines: This section determines one’s knowledge of business architecture as it relates to related business disciplines that include business model alignment, business process management, case management and business requirements analysis.
5. Business Architecture & Business Performance Analysis: This section examines one’s understanding of using business architecture to assess how well each aspect of the business is performing and includes performance metrics, initiative assessments and portfolio planning.
6. Business Architect Role: This section assesses one’s knowledge of the business architect’s role, responsibilities, competencies and interactions with related roles.
7. Business Architecture Governance: This section assesses one’s knowledge of business architecture team setup, organizational alignment, stakeholder engagement and all of the components necessary to successfully deploy, mature, measure and sustain a business architecture program.
8. Business Architecture & IT Architecture Alignment: This section determines one’s ability to leverage business architecture in IT architecture assessments, portfolio management, engagement with application, data and solution architects, and business / IT transformation initiatives.
9. Business Architecture Situation & Scenario Usage: This section tests one’s understanding of how to apply business architecture in various business situations and include issue analysis and resolution, impact analysis, change management, customer experience and other common business scenarios.
10. Business Architecture Infrastructure Management: Infrastructure management examines one’s ability to manage and package business architecture artifacts and reporting and includes a basic understanding of the role of knowledgebase structure and tooling considerations.
Business Architecture Guild:
Certified Business Architect(CBA)® Program
Certified Business Architect(CBA)® – Certification Exam Domains & Objectives
This document provides defines the domain categories and related objectives for each business architecture certification exam domain category.
1.0 Business Architecture Foundational Concepts: The section assesses basic understanding of general business architecture concepts, core versus extended business mapping disciplines, scenario use and context, and overall value proposition.
1.1 Objective: Test candidate’s knowledge of business architecture’s purpose, scope, principles and value proposition
1.2 Objective: Test candidate’s knowledge of the business architecture ecosystem
1.3 Objective: Test candidate’s knowledge of the Business Architecture Framework
2.0 Business Architecture Core Mapping Knowledge: Core mapping disciplines test one’s knowledge of creating and using capability, value, organization and information maps and the interaction among these disciplines.
2.1 Objective: Test candidate’s knowledge of capability mapping
2.2 Objective: Test candidate’s knowledge of value mapping
2.3 Objective: Test candidate’s knowledge of organization mapping
2.4 Objective: Test candidate’s knowledge of information mapping
3.0 Business Architecture Extended Mapping Knowledge: The extended mapping disciplines section examines one’s knowledge of strategy mapping, stakeholder mapping, initiative mapping and product and service mapping.
3.1 Objective: Test candidate’s knowledge of strategy mapping
3.2 Objective: Test candidate’s knowledge of stakeholder mapping
3.3 Objective: Test candidate’s knowledge of initiative mapping
3.4 Objective: Test candidate’s knowledge of product mapping
3.5 Objective: Test candidate’s knowledge of policy mapping
4.0 Business Architecture Alignment with Related Business Disciplines: This section determines one’s knowledge of business architecture as it relates to related business disciplines that include business model alignment, business process management, case management and business requirements analysis.
4.1 Objective: Test candidate’s knowledge of business architecture alignment with business model frameworks
4.2 Objective: Test candidate’s knowledge of business architecture alignment with business process modeling
4.3 Objective: Test candidate’s knowledge of business architecture’s use in conjunction with business requirements analysis
4.4 Objective: Test candidate’s knowledge of business architecture alignment with case management
4.5 Objective: Test candidate’s knowledge of business architecture alignment with Lean/Six Sigma
5.0 Business Architecture & Business Performance Analysis: This section examines one’s understanding of using business architecture to assess how well a business is performing and includes performance metrics, initiative assessments and portfolio planning.
5.1 Objective: Test candidate’s knowledge of basic performance management concepts
5.2 Objective: Test candidate’s knowledge of heat mapping usage and practice in business architecture
5.3 Objective: Test candidate’s knowledge of business performance measurement
5.4 Objective: Test candidate’s knowledge of how business performance management is applied
6.0 Business Architect Role: This section assesses one’s knowledge of the business architect’s role, responsibilities, competencies and interactions with related roles.
6.1 Objective: Test candidate’s knowledge of his or her role in stakeholder and relationship management
6.2 Objective: Test candidate’s knowledge of the business architect as a leader and a facilitator
6.3 Objective: Test candidate’s knowledge of his or her role as advisor, mentor
6.4 Objective: Test candidate’s knowledge of communicating, persuading and presenting
6.5 Objective: Test candidate’s knowledge of the competencies of a business architecture practitioner
7.0 Business Architecture Governance: This section assesses one’s knowledge of business architecture team setup, organizational alignment, stakeholder engagement and all of the components necessary to successfully deploy, mature, measure and sustain a business architecture program.
7.1 Objective: Test candidate’s knowledge of the roles involved in business architecture governance
7.2 Objective: Test candidate’s knowledge of business architecture governance structures
7.3 Objective: Test candidate’s knowledge of business architecture team purpose and principles
7.4 Objective: Test candidate’s knowledge of how to scale business architecture efforts
7.5 Objective: Test candidate’s knowledge of applying business architecture in an organization
7.6 Objective: Test candidate’s knowledge of assessing the maturity of a business architecture deployment
8.0 Business Architecture & IT Architecture Alignment: This section determines one’s ability to leverage business architecture in IT architecture assessments, portfolio management, engagement with application, data and solution architects, and business / IT transformation initiatives.
8.1 Objective: Test candidate’s knowledge of business and IT architecture alignment
8.2 Objective: Test candidate’s knowledge of leveraging business architecture under the broader perspective of enterprise architecture
8.3 Objective: Test candidate’s knowledge of the use of business architecture for application portfolio management
8.4 Objective: Test candidate’s knowledge of the role of business architecture in the context of services-oriented architecture (SOA)
8.5 Objective: Test candidate’s knowledge of business architecture and data management and data architecture
8.6 Objective: Test candidate’s knowledge of business architecture’s role in business / IT transformation
9.0 Business Architecture Situation & Scenario Usage: This section tests one’s understanding of how to apply business architecture in various business situations and include issue analysis and resolution, impact analysis, change management, customer experience and other common business scenarios.
9.1 Objective: Test candidate’s knowledge of how to use business architecture in various assessment situations
9.2 Objective: Test candidate’s knowledge of how business architecture applies to transformative scenarios
9.3 Objective: Test candidate’s knowledge of how business architecture applies to smaller scale, tactical scenarios
9.4 Objective: Test candidate’s knowledge of where various aspects of business architecture would be applied in certain situation analysis and in what context
10.0 Business Architecture Infrastructure Management: Infrastructure management examines one’s ability to manage and package business architecture artifacts and reporting and includes a basic understanding of the role of knowledgebase structure and tooling considerations.
10.1 Objective: Test candidate’s knowledge of business architecture knowledge management and related knowledgebase
10.2 Objective: Test candidate’s knowledge of automation options for managing the business architecture
he definition I’m considering at this time is:
Business Architecture is
1. A specialization of the Enterprise Architecture business function that collects and manages functional, structural, and motivation-related information using a rigorous scientific and engineered approach for the purposes of business design, functional improvement, motivational alignment and decision support. [Updated, 5 Sept 12]
2. A subset of the architectural description of an enterprise sufficient to produce models that meet the functional, motivational, and alignment concerns of stakeholders. [Updated 11 Sept 12]
Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.
miércoles, 13 de mayo de 2015
domingo, 10 de mayo de 2015
Leading Organizational Redesign with Business Architecture
jueves, 7 de mayo de 2015
miércoles, 6 de mayo de 2015
lunes, 4 de mayo de 2015
domingo, 3 de mayo de 2015
sábado, 2 de mayo de 2015
viernes, 1 de mayo de 2015
Tripling the Odds of Transformation Success: A Critical Role for Business Architecture
miércoles, 29 de abril de 2015
Enterprise adaptation to technology change is key to survival
Do we need an Enterprise Architecture Theory? We do.
Does Enterprise Architecture really enable the enterprise transformation?
MEGA named leader by Forrester for Strategic Planning for the BT agenda
jueves, 23 de abril de 2015
lunes, 20 de abril de 2015
Enterprise architecture is widely misunderstood, and there is a deficit of trained and educated architects that can conceive of the full scope. There are several basic concepts you should be aware of in understanding enterprise architecture. Different schools of thought treat these differently, some including this and excluding that as adjacent, but they are each part of that picture. These concepts include:
- Strategic Planning
- Strategic Advantage
- Line of Business
- Business Processes
- IT Investment
- Return on Investment
If your enterprise architects do not see the full picture and do not understand these basic concepts, you are not getting the full value of enterprise architecture. If you are an enterprise architect and do not see the full picture or do not comprehend how these basic concepts relate to your practice, you are not delivering the full value to the customer. As training, education and certification improve the full picture should, over time, become better understood.
Enterprise architecture is closely associated with strategic planning or IT strategic planning. Some view enterprise architecture as planning. A common main output of the enterprise architecture activity is a transition plan (aka roadmap or transformation plan).
Steven H. Spewak’s book “Enterprise Architecture Planning, Developing a Blueprint for Data, Applications and Technology” ISBN 0-471-59985
Another book: Jeanne W. Ross et. al. “Enterprise Architecture as Strategy: Creating a Foundation for Business Execution” ISBN 1-59139-839-8
John A. Zachman: “During the 1980′s, I became convinced that architecture, whatever that was, was the thing that bridged strategy and implementation”.
The top policy for enterprise architecture of the U.S. Federal Government, OMB Circular A-130, transmittal 4, identified strategic planning as a direct input to enterprise architecture.
Implementation of something is why you do an architecture. If you are implementing nothing there is little need to do an architecture. Without implementation the ROI (retun on Investment) for architecture is quite restricted, consisting of cost savings for what you did not implement.
John A. Zachman: “During the 1980′s, I became convinced that architecture, whatever that was, was the thing that bridged strategy and implementation”.
Atchitecture is about designing something to be constructed. It is a primarily visual practice communicated through drawings and specifications.
Definitions of ARCHITECTURE (ar·chi·tec·ture \ˈär-kə-ˌtek-chər\)
Merriam Webster: 2a : formation or construction resulting from or as if from a conscious act architecture of the garden> b : a unifying or coherent form or structure architecture>… 5 : the manner in which the components of a computer or computer system are organized and integrated
Dictionary.Com: 1: the profession of designing buildings, open areas,communities, and other artificial constructions and environments, usually with some regard to aesthetic effect.Architecture often includes design or selection of furnishings and decorations, supervision of construction work, and the examination, restoration, or remodeling of existing buildings.
Architecture is commonly considered to be a visual process. In architecture it is common to produce a “vision” or picture of the future state. Enterprise architecture also commonly produces a vision of the future (aka target or to-be) state. It is this vision which is commonly used to convince stakeholders to buy in to the direction and process of the architecture.
- In the TOGAF framework there is a phase named “vision”.
- In the FEAF one output is a vision.
- In the DODAF the OV-1 CONOPS diagram provides a visual depiction of the future state, essentialy a vision.
Alignment in enterprise architecture is when all the efforts “line up” to support the organizational strategy, or when lower level detail supports higher level architecture. When all the artifacts agree, you have “alignment”. Alignment is often checked by governance.
One FEAF artifact, the “line of sight diagram” is a depiction of the project linked through improved performance measures to business outcomes and the organizational strategic goals.
Transformation (aka business transformation or transformation of government) is the concept of changing the organization and its processes or structures to improve performance. Enterprise architecture is about transformation, expressing a current state a target state and a transition plan.
Strategic Advantage (Differentiators, Capabilities)
When a strategic goal or goals (aka “mission needs”) are supported by an executable implementation the result is a “strategic advantage”. A “strategic advantage” may also be called a differentiator (commercial use) or a “capability” (mainly government use). Enterprise architecture is commonly and routinely associated with the production of these “capabillities” or “differentiators” that constitute a “strategic advantage”. Many are unaware of this linkage because of disparate terminology, but one common definition of enterprise architecture is “the link between strategy and execution” which is again roughly synonamous. Michael Porter called this Competiitive Advantage.
- TOGAF 9 includes a section of capabilities based planning
- DODAF is tightly associated with JCIDS (Joint Capabillities Integration and Development System).
- DODAF 2.0 includes a capabilities metamodel.
- Zachman International provides seminars for using EA to produce business advantage.
Definition of Technology (tech·nol·o·gy [tek-nol-uh-jee] noun):
… 4. the sum of the ways in which social groups providethemselves with the material objects of their civilization. (dictionary.com)
As the term is used here, technology is th basis of all strategic advantage, differentiators or capabilities. Initially EA was associated with only information technology, but wider applicability has since occurred.
In 1983 a classified program was initiated in the US intelligence community to reverse the US declining economic and military competitiveness. The program, Project Socrates, used all source intelligence to review competitiveness worldwide for all forms of competition to determine the source of the US decline. What Project Socrates determined was that technology exploitation is the foundation of all competitive advantage and that the source of the US declining competitiveness was the fact that decision-making through the US both in the private and public sectors had switched from decision making that was based on technology exploitation (i.e., technology-based planning) to decision making that was based on money exploitation (i.e., economic-based planning) at the end of World War II.
Technology is properly defined as any application of science to accomplish a function. The science can be leading edge or well established and the function can have high visibility or be significantly more mundane but it is all technology, and its exploitation is the foundation of all competitive advantage.Technology-based planning is what was used to build the US industrial giants before WWII (e.g., Dow, DuPont, GM) and it what was used to transform the US into a superpower. It was not economic-based planning.
Project Socrates determined that to rebuild US competitiveness, decision making throughout the US had to readopt technology-based planning. Project Socrates also determined that countries like China and India had continued executing technology-based (while the US took its detour into economic-based) planning, and as a result had considerable advanced the process and were using it to build themselves into superpowers. To rebuild US competitiveness the US decision-makers needed adopt a form of technology-based planning that was far more advanced than that used by China and India.
Line of Business aka Value Chain or Value Stream
A “line of business” is a particular product line. The term is also applied in EA to any functional area, including human capital, financial management, or logistics. A “line of business” is often the basis of an architecture inside the enterprise, and corresponds to the terminology “segment” used in Burk’s levels. Another term of similar use if “domain” as in “domain architecture”. A “line of business” may be a mission area or profit center, or it may be a support function or cost center. In EA the idea is to give priority to those areas that are important to the mission or produce profit.
In enterprise architecture the “line of business” or segment or domain is the level at which most business process reengineering, value chain analysis, supply chain analysis, operational analysis etc. occurs. An example of this is the Federal Segment Architecture Methodology. Another example is the Business Transformation Architecture (BTA) effort at DoD.
In enterprise architecture the “framework” holds a special role. In my opinion this is because enterprise architecture practice began with competing vendors in system integration, not in academia. Each participating company produced some competing conceptual model, and later this practice was adopted by government to conceptualize various parts of the practice. There are different types of frameworks, applicable to different levels and layers and mechanisms in the scope of enterprise architecture:
- Frameworks for solution architecture (DODAF, TOGAF)
- Frameworks for enterprise level architecture (ZIF, FEAF)
- Frameworks for segment (Line of Business) architecture (FSAM, DODAF tailored)
- Frameworks for enterprise architecture maturity (EAMMF)
- Frameworks for sequence, such as an SDLC (INCOSE SDLC, IEEE SDLC, DoD SDLC, DHS SELC)
- Frameworks for data or information architecture (Martin’s Information Engineering, Oracle Case Method tm)
- Frameworks for business architecture (Hammer’s BPR…)
- Frameworks for software architecture (Booch, SEI, UML)
- Frameworks for standards and infrastructure (COBIT)
- Frameworks for shared services (ITIL)
(Some believe in the ultimate “uber-framework”, a mythical super-method like the “theory of everything” in physics. Personaly, I do not think frameworks should be expanded from their focus, where they are excellent, into areas of mediocrity. For the moment we must use multiple frameworks, or parts of several. I suggest picking a minimum set and using them with improving maturity. Standard, public frameworks are superior to proprietary frameworks for which one must pay: Avoid being held hostage by vendors of frameworks with recurring fees or mandatory services.)
Artifacts come in various types:
Architecture & Engineering Drawings
Artifacts are the concrete output (deliverables) of an enterprise architecture effort. Sometimes these may be embodied in data inside a tool so you can create new artifacts on the fly. Artifacts (and the facts or plans they represent) are reviewed and approved via governance.
Enterprise architecture is the fusion of business and technology. This is accomplished in large part through business processes analysis and reengineering or continuous process improvement, the very same techniques used in human resources, operations management, logistics and supply chain management, Six Sigma, and TQM.
The US Government defines enterprise architecture in OMB Circular A-130: “What is the Enterprise Architecture? (a) An EA is the explicit description and documentation of the current and desired relationships among business and management processes and information technology.”
DODAF and derivatives include business process diagrams, and in DODAF these are labled “OV-5″ or operational view number five.
TOGAF identifies “Phase B” as business architecture, including business process analysis.
Levels in Enterprise Architecture
In 2006 Dick Burk, Chief Architect at OMB at the time, identified that enterprise architecture has different levels. This important conflict deconflicted endless arguments between architects at the tactical (solution) level and the strategic (enterprise) level. With the concept of levels in enterprise architecture practice it is now possible to see that there are three different kinds of activity with different scope possibly performed by three different teams (or more). Without this concept your EA efforts may become tactical and without strategic impact, or strategic but without concrete results.
Layers (aka Columns, Areas)
The concept of layers should not be confused with Burk’s concept of levels of enterprise architecture. In the NIST model five layers were identified (business, information, application, data, infrastructure), and these were modified for the FEAF framework as four levels (business, data, application, technology). Both are related to Zachman’s columns (all three images are from the FEAF where this is discussed). One could make a case that thiese layers relate to DODAF views as well. The concept of “layers” implies a flow from one to another, a precedence or order, as descrivet in NIST. Each of these layers consitiutes a different area or specialization in architecture and often a different member of the enterprise architecture team.
In enterprise architecture governance is used in the sense of corporate IT compliance, in the sense of Sarbanes-Oxley or Basil II. IT systems must comply with various laws, policies, plans, standards and higher level architecture. Enterprise architecture artifacts and system engineering plans are reviewed by governance processes. Those processes vary by organization.
Conversely actual systems are checked for compliance via testing.
IT (Information Technology) Investment
For several years now information technology has been managed as an investment. It is seen not as a cost of doing business, but as a means to improve operations. Information technology and IT systems have become massively expensive in large corporations and especially the U.S. Federal Government, and just buying some software because it seems useful is no longer justifiable. Each IT purchase is now managed as a means to effect organizational change, a way to make the organization perform. The cost is compared not to the system features and functions, but to the improvement in organizational operations and the decreased operations cost or increased revenue that will result.
This approach can be applied to any technology purchase, not just IT.
Return on Investment
The purchase of more information technology is treated as an investment. To justify the investment there must be a return on that investment, payback.
The return on any investment, including an IT investment, you list the tangible and intangible costs versus the tangible and intangible benefits. A document containing this information and making any ROI calculations is often called a Cost Benefit Analysis.
The benefits to the procuring organization are not system features but improved organizational operations. In the U.S. Federal Government more benefits are intangible, because it is politically infeasible to measure the dollar value of human suffering, starvation, death, or other things that may be affected by government operations.
Enterprise architecture improves organizational performance using technology, by leveraging technology investment. Organizational performance is made tangible by the use of performance measures. Performance measures may relate to money (cost, price), quality or timliness (throughput, volume). Any product or service or entire company can be measured in these categories.
Any business process can be measured and improved. These improvements also fall in the three basic categories of money (cost, price), quality or timeliness (throughput, volume). When you automate or streamline some business process these measures change. Such a change in performance constitutes the return on investment of the automation.
A measurable change in measured performance indicators is sometimes called a “business outcome”. When a new capability is operationally implemented you get a business outcome.
How do you decide which technology improvements to make in your organization, and which to cancel? If technology and IT procurement is treated as an investment, then you treat the question as a portfolio of investment. You perform portfolio management.
A portfolio of investment lists each investment, its cost, its level of return (return on investment), and its risk. You put the investment with the highest ROI at the top. Eliminate all the poor investments. Working from the top down, you draw a red line when you run out of budget for these investments. The investments above the line are what you fund, and those below are what you cancel.
As your investment proceeds you monitor that it performs as predicted. If the return drops or the risk spikes you review the investment for cancellation.
Systems (Theory & Engineering)
For some time the western world believed that if you could list every part of a thing, you understood that thing. Ludwig Von Bertanalfy changed that with general system theory. In GST things have interactions and you need to understand that. They have interfaces. Interactions may follow patterns, like strange attractors or cycles ammenable to Fourier analysis, or they may have cybernetic feedback.
Some such systems with many interactions may be complex. If you build a complex system you may need means to control and specify so many parts that no one person can grasp the whole thing. You may need system engineering. It has means to manage complexity.
Systems may be defined, like boxes. You may treat the internals as unknown and just specify the interfaces, black boxes. You may see inside and treat them as white boxes.
The enterprise is a system. Each IT investment is a system. Integrated sets of IT are systems. EA is meaningless without the concepts related to systems.
Systems have a lifecycle. Typicaly there is a systemm development lyfecycle (provided by systems engineering) with stage-gates to mark major phases and transitions. The system is concieved, planned, developed, tested, operated and later disposed of. One system replaces another. All this takes time, and planning. Without that one system will break down as unsupporable and you may be in a huge rush to replace it with anything, perhaps not the best replacement, and you may be willing to spend extra to do it. The results of planning are reflected in the enterprise transition plan.
Investments also have a lifecycle, with reviews. These mark the ROI and the breakeven points, and should also be reflected in the transition plan.
Enterprise Architecture is a term initially coined within the context of addressing problems of system integration. To share information and support business processes from end to end it is typical to integrate systems together. Some years ago Manufacturing Resource Planning susye,ms were connected to accounting systems and ERP resulted, for example. There is still a strong need to connect systems together, via SOA, EAI, ESB or other means.
When you take items vended as a system, like ERP, and connect them to other systems you get a system of systems.