Drivers: changes, changes dynamics, change rate and speed, unexpected challenges, unpredictable context
Effects: risks, instability, flux, timing/duration unknown

Drivers: unpredictability, potential surprises, unknown outcomes, we don't know what we don't know, what we don't know increases
Effects: lake of direction, no risk taking, paralysis preventing action

Drivers: overwhelming amount of information (big data Vs), tasks correlation, multifaceted effects, influencers, interdependencies,
Effects: unproductively, dilemas, inability to stand for CONs of any decision

Drivers: ideal vs. actual, many stakeholders, contradictory inputs, diverging interests/opinions, causal relationships are unclear, no precedents
Effects: doubt, distrust, lapses in decision-making, hurt innovation

• Volatility: need for a clear vision, take actions, probe changes, react quickly
• Uncertainty: collect enough knowledge, have a wide understanding, different perspectives, cope with complexity
• Complexity: simplification, creativity, clear focus, flexibility, clarity
• Ambiguity: agility, decision-making, fast prototyping, innovation

One reason we have found why project success rates are so poor is the low level of maturity of technologies available for managing them. Most organizations and project leaders are still using spreadsheets, slides, and other applications that haven’t evolved much over the past few decades. These are adequate when you are measuring project success by deliverables and deadlines met, but they fall short in an environment where projects and initiatives are always adapting — and continuously changing the business. There has been improvement in project portfolio management applications, but planning and team collaboration capabilities, automation and “intelligent” features are still lacking.

1. Better selection and prioritization
2. Support for the project management office
3. Improved, faster project definition, planning, and reporting
4. Virtual project assistants
5. Advanced testing systems and software
6. A new role for the project manager

• Based on "Divide to better rule"
• It is essential to decompose a complex system into smaller and smaller parts, each of which we may then refine independently
• understand any given level of a system, we need only comprehend a few parts (rather than all parts) at once

• ... be available to all team members, to facilitate collaboration and iteration.
• ... be easily changeable, as a continuous reflection of up-to-date information.
• ... contain both visual and written forms of diagramming, to better explain the abstract concepts it may represent.
• ... establish relevant terms and concepts
• ... define said terms and concepts
• ... provide a basic structure for entities for a scope (domain, project...)

• Unified Modelling Language (UML)
• Resource Description Framework (RDF)

• Development KPIs
• Running & usage KPIs
• Business performance KPIs

• Provide objective evidence of progress towards achieving a desired result
• Measure what is intended to be measured to help inform better decision making
• Offer a comparison that gauges the degree of performance change over time
• Can track efficiency, effectiveness, quality, timeliness, governance, compliance, behaviors, economics, project performance, personnel performance or resource utilization
• Are balanced between leading and lagging indicators
• Ideally automated

• Who, what, how: Be clear about who the audience is, what they want, and how they’re going to use the KPIs. This means working with your stakeholders to identify the core KPIs that map directly to their goals and strategy.
• SMART: Specific, Measurable, Attainable, Realistic, and Time-bound. 
  Iterate and evolve: Over time, see how you or your audience are using the set of KPIs and if you find that certain ones aren’t relevant, remove or replace them.

See also Objectives and Key Results

Agile was designed to better develop websites for which developers have clear requirements

Developing AI/ML digital products and service requires to take in account other factors such as

1. DS/AI projects requires a lot of experimentation; the outcome of Probabilistic models in ML is not the same as a user requirement
2. DS/AI projects success depends on input data quality (often underestimated and not considered as part of the project by sponsors); quality data is a must-have to train a ML model
3. DS/AI projects require specific measures of success
   • A model being successful in terms of accuracy may not mean that there will be business benefits from the outputs
   • Hard to measure what is a 80% good enough solution; requires post-deployment adjustment/maintenance

Source to PMI paper: https://www.pmi.org/learning/library/playbook-data-science-artificial-intelligence-projects-13322

1. Capture business needs, problems, questions, requirements
2. Define metrics to measure success when product is released
3. Identification of key business concepts
4. Create the corresponding semantic model
5. Identification and characterization of relevant sources
6. Identify relevant standards
7. Develop a machine-learning model (NLP)
8. Access data/experts to train the model
9. Feed model outcome to the knowledge graph
10. Expose MVP
11. Link MVP outcomes to initial needs
12. Use metric to measure success and further develop product
13. Goes back to point # 1

Because all Agile+ metadata is collected in a semantic knowledge graph, this methodology is

• Digital i.e. machine readable and queriable
• Agile
• FAIR by-design
• Sustainable (using open standards)
• Transparent (the content of the graph is business-use validated and displayed/queried transparently)
• Integrated (this is linked data)
• Success measurement is embedded in the methodology
• Low-risk (no business disruption)
• Cost-efficient (no vendor lock-in)

1️⃣ Success is defined by business questions, not technical
Start with the business questions you want answers to – know WHO is asking and WHY! And no tech-talk, please! Understand how that question is being answered today and quantify it. Measure the new solution's improvement based on that!

2️⃣ Have the right people in the room
Three personas: 1) Business folks: provide the business question and live the day to day pain 2) Data engineer: built the data lake, write ad-hoc queries, know where the bodies are buried 3) Knowledge engineer: bridge between data and business, "people person" with the business users and geek out with the data folks. They grasp the business context even if it's outside their domain, translate it to the technical language. Push back on both the business and data folks when something is not aligning. 

3️⃣ The Pay as you Methodology
Don't throw sh** at the wall. You must have a methodology. We follow the Pay as you go Methodology (link in comments). Start with a question (aka competency question) and go through three phases 1) Knowledge capture: understand the question, capture the concepts, attributes and relationships represented in the questions, identify where is the granular data to answer those questions. This becomes the ontology and mappings 2) Knowledge implementation: formalize the ontology and mappings as code 3) Chat with the data: set up the system, test, validate. Iterate for the next question

4️⃣ Get unstuck with the Iron thread approach
Take a specific instance, for example a Customer by ID. In the ontology: customers places Orders, etc. Look up the customer id in the original source system and see how many orders they should have. Then check the mappings and see if you get the same results. If you aren't, you found the problem. If you are, keep going. Eventually you will have that thread that will go through the ontology. Try it again with another customer ID. The thread gets stronger.  

5️⃣ Eating your vegetables can be fun
The conclusion of our benchmark research is that by investing in knowledge graphs, the accuracy of question answering over enterprise sql data with LLMs increases. The key word here is "investing" and this means starting with a strong foundation of metadata and semantics. This may feel like eating your vegetables. The objective isn't to have a perfect metadata of all your data estate. That's infeasible. Just have it for the parts that are going to be used in answering the questions. When you go through the methodology and the iron thread, you will be learning a lot about the data and the business. Add all those learnings in the data catalog. Start small, think big

It is all about people

• Get knowledge:
  • Internally -> education
  • Externally -> special consultants
• Maintain knowledge:
  • Small business/scope: 1 FTE
  • Large business/scope: knowledge management team

Architecture and tech stack

• Build basic framework:
  • Small business/scope: open-source solutions, 3-6 months, CHF 20-50k
  • Large business/scope: professional solutions, 6-24 months, CHF 120-500k
• Maintain framework:
  • Small business/scope: 5k per year
  • Large business/scope: 80-120k per year

An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of organizations. The intent of enterprise architecture is to determine how an organization can effectively achieve its current and future objectives. Enterprise architecture involves the practice of analyzing, planning, designing and eventual implementing of analysis on an enterprise.

Enterprise architecture helps businesses going through digital transformation, since EA focuses on bringing both legacy applications and processes together in an attempt to form a seamless environment. The use of EA frameworks rose in response to increases in business technologies during the 1980s, when a need for a way to respond to rapid technology growth was integral to business strategy. This process later expanded to the entirety of a business, not just IT. This way, the rest of the business would be ensured to be aligned with digital transformation.

Concepts of enterprise architecture are variable, so it will not look the same for each organization. Different parts of an organization may also view EA differently. For example, programmers and other technical IT professionals regard enterprise architecture strategies in terms of the infrastructure, application and management components under their control. However, enterprise architects are still responsible for enacting business structure analysis.

Enterprise architecture will help multiple departments in a business understand the broader business model and articulate challenges and business risks. Because of this, enterprise architecture has an important role in unifying and coordinating departmental processes across an organization. Being able to access and understand business capability should also help individuals identify gaps in their business, and from there, they can make more informed decisions.

The main goals of enterprise architecture may be to create a map or blueprint of the structure and operations of an organization. This blueprint should include information such as a map of IT assets and business processes.

Other common goals include promoting team alignment and standardization. This can be done in part by unifying environments across teams and organizations. Guidance is normally based on an organization's business requirements.

Microsoft's Michael Platt, a director in the strategic projects group, offers a view of enterprise architecture as containing four points of view: the business perspective, the application perspective, the information perspective and the technology perspective. The business perspective defines the processes and standards by which the business operates on a day-to-day basis. The application perspective defines the interactions among the processes and standards used by the organization. The information perspective defines and classifies the raw data (such as document files, databases, images, presentations and spreadsheets) that the organization requires to operate efficiently. The technology perspective defines the hardware, operating systems, programming and networking tools used by the organization.

The term may have various meanings to professionals in different areas who work with different EA frameworks. For example, programmers and other technical IT professionals regard enterprise architecture strategies in terms of the infrastructure, application and management components under they have control over.

High-level programmers will use enterprise architecture when referring to the hardware and software components in a design. For a website, that might comprise a web server, database, the NoSQL database cache, the API endpoints and the content delivery network.

For technical enterprise architecture descriptions, EA could revolve around the context of software architecture, systems architecture deployment types and other steps like testing.

Others could view enterprise architecture based on quality attributes. These are attributes that must exist for software to work and are unlikely to fit in a specification document. Examples include reliability, capacity, scalability and security. Quality elements are not functional requirements, but are ways to determine acceptable operating conditions and necessary tradeoffs to get there.

Enterprise architecture, in a business context, may have organizations distinguish their enterprise architecture from the technical architecture required to build and run applications. Working from within an enterprise architecture framework will help define this.

Enterprise architectures are typically implemented as frameworks. There are many different frameworks, and some will be a better fit than others when it comes to any one organization. For example, a framework focused on consistency and relationships between various parts of an overarching enterprise will be more helpful to larger organizations with many moving parts compared to small ones. In this case, a framework like the Unified Architecture Framework (UAF) may work.

Some example frameworks include:

• The Zackman framework for Enterprise Architecture -- which covers six architectural points as well as six primary stakeholders that aid in defining and standardizing IT architecture components.
• Unified Architecture Framework (UAF) -- which is a complex but flexible enterprise architecture framework suitable for military and government software development as well as use in commercial businesses. It's implemented as a UML profile.
• Open Agile Architecture -- which focuses an organization around a flexible, extended collection of structures and processes that can grow. It can become an important part of Agile software delivery.
• Federal Enterprise Architecture Framework (FEAF) – which is a reference model that was introduced in 1996 for IT effectiveness. It was designed for the U.S. government but can be used in private companies as well.

Other frameworks include The Open Group Architectural Framework, the European Space Agency Architectural Framework, the SAP Enterprise Architecture Framework or the Ministry of Defence Architecture Framework.

Possible advantages of having an enterprise architecture include:

• Improved decision-making;
• Improved adaptability to changing demands or market conditions;
• Elimination of inefficient and redundant processes;
• Optimization of the use of organizational assets;
• Minimization of employee turnover;
• Support organization changes for redesigns and reorganization;
• Makes it easier to evaluate architecture against long-term goals;
• Can give views of IT architectures to those outside of IT;
• Can help with the unification of processes in IT;
• Can help simplify finance teams; and
• Facilitates collaboration with project management.

Several third-party vendors and tools sell enterprise architecture products, as well as some certifications that center around certain skills.

Some example vendors include Orbus Software, Software AG, Planview, Avolution and Sparx Systems.

ServiceNow Project Portfolio Management is an example of one EA tool, used for full visibility. It can keep everyone from different departments on the same page, from Sales to IT. It is relatively easy to configure and allows users to pick the management type -- such as agile -- for each project. However, it may be difficult to use for resource management.

Oracle Enterprise Architecture Framework is another example of an EA tool. The software helps users in developing strategic roadmaps and architectures that enable business and IT alignment. This software is driven by business strategies and simplifies technical architectures; however, it may be difficult to use for beginners.

Some example certifications include:

• Salesforce Certified Technical Architect
• The Open Group Certified Architect
• AWS Certified Solution Architect
• Professional Cloud Solutions Architect Certification
• Certified Information Systems Security Professional-Information Systems Security Architecture Professional