Applied BA Cookbook
Thirty-five problem-centered methods for applied business architecture work.
Search the workbench
Find a recipe, field note, public source, download, study resource, or SCALE entry without knowing where it lives first.
Showing the main starting points. Enter a term to search all indexed content.
Thirty-five problem-centered methods for applied business architecture work.
Curated public standards, guides, white papers, tools, and original downloads.
A disciplined, public-information-based approach to studying the BIZBOK system and preparing for the CBA examination.
A BA-led decision-support design for answerable, governed business architecture knowledge.
Long-form writing on judgment, institutions, stakeholder work, AI, governance, and operating models.
Structured email help for one real business architecture question and limited practitioner mentoring.
The request arrives as a solution, a vague transformation, or a demand for “a capability map.”
The first draft mirrors departments, applications, or process steps instead of stable business abilities.
The “value stream” becomes a swimlane full of activities, systems, and handoffs.
Scope is expressed as features, applications, or a project charter with no enterprise impact logic.
Objectives, capabilities, initiatives, and metrics exist in separate decks and cannot explain one another.
Architecture review becomes a document checkpoint rather than a forum for resolving consequential choices.
The organization wants BA but starts with a huge metamodel, a tool purchase, or an unfunded center of excellence.
The workshop succeeds, but the whiteboard dies in a deck and the enterprise relearns the same facts later.
The practice begins with enthusiasm but no shared purpose, boundaries, decision rights, engagement model, or definition of success.
The information model has become a long, inconsistent list that mixes genuine business objects with synonyms, attributes, documents, events, roles, applications, and local terminology.
Business information is documented, but the organization cannot show where it enters the business, which capabilities change it, how it moves through value delivery, or who governs its lifecycle.
The capability map is either too shallow to support a decision or decomposed into uneven detail that nobody can consistently assess, own, or use.
An existing capability map is dominated by departments, roles, processes, applications, products, and duplicated local abilities, but stakeholders already depend on it and replacing it wholesale would destroy useful knowledge and credibility.
A broad statement such as “improve customer experience” or “modernize operations” creates activity, but it does not identify the outcomes, business changes, evidence, or choices needed for execution.
A portfolio contains differently named initiatives whose intended outcomes, capability changes, value-stream impacts, information needs, systems, or dependencies partially duplicate or conflict with one another.
A discovery meeting is scheduled before the decision, participants, evidence, working structure, and expected outputs are clear, so the session produces broad conversation instead of usable architecture knowledge.
A capability model needs business validation, but the workshop risks becoming an unstructured debate about department names, process steps, systems, terminology, and personal ownership claims.
Two groups use different terms, definitions, or boundaries and each insists that its version represents a separate capability, leaving the enterprise with duplication, false standardization, or unresolved ownership conflict.
A capability map has been colored red, yellow, and green without a clear decision, consistent dimensions, defensible evidence, or any indication of confidence, creating visual certainty without analytical discipline.
The first release is either overloaded with desirable scope or reduced to a technical component that cannot produce usable business value on its own.
An initiative remains nominally active but repeatedly misses decisions, funding, dependencies, or mobilization, while status reporting describes delay without identifying the constraint that must actually change.
A broad transformation is divided by department, application, funding source, or delivery team, producing work packages that cannot independently explain their value, dependencies, or contribution to the intended business change.
A capability roadmap either remains a timeless aspiration or becomes a delivery schedule full of projects, tasks, and dates that obscures the business abilities and outcomes being changed.
A requirement is documented and prioritized without a durable explanation of which stakeholder outcome, value-stream stage, capability change, information need, policy, or initiative decision justifies it.
A platform, application, or emerging technology is presented as the solution before the desired outcome, capability gap, value-stream impact, information need, operating-model change, and policy implications have been established.
Business architecture is expected to create enterprise value without the mandate, access, funding, or decision rights normally supplied by an executive sponsor.
Business architecture sits inside an organization whose governance, funding, language, and demand are centered on technology, creating pressure to become an upstream solution-design service instead of a business decision discipline.
Multiple business units claim to own one capability because ownership is being used to mean content stewardship, investment authority, performance accountability, policy control, or operational execution at the same time.
Business architecture is added as a separate review, template, or approval gate, increasing cycle time while portfolio decisions continue to rely on the same incomplete strategic and business evidence.
The EA repository is becoming either an indiscriminate document store or an incomplete diagram catalog, while practitioners duplicate authoritative data and struggle to decide which knowledge deserves governed relationships and lifecycle control.
A proposed strategy, policy, business model, or emerging concept needs architectural analysis before implementation exists, creating pressure either to invent a target solution or to postpone useful modeling until decisions have already hardened.
When an initiative is cancelled, merged, defunded, or abandoned, validated enterprise knowledge disappears with its project files while obsolete scope, target states, and assumptions remain discoverable without clear status.
Architecture from a prior initiative is copied into a new context as an assumed standard, carrying forward local choices, stale assessments, ownership, and constraints that may not represent durable enterprise knowledge.
Teams either model process by habit when capability and value views would answer the decision, or avoid process detail when sequence, handoffs, controls, timing, and exception behavior are essential.
Architecture continues because the enterprise can always be modeled more completely, or it ends when a deadline arrives without confirming that the decision, governance, and downstream consumers have what they need.
Stakeholder engagement is not an accessory to business architecture. Observation, meeting preparation, facilitation, humor, and the ability to read a room directly affect the quality of the architecture we produce.
How business architects can govern an unruly business object model, preserve canonical business meaning, model lifecycles and states, and connect business objects to automation without collapsing business architecture into data or solution design.
Selecting an enterprise architecture platform for business architecture requires testing how well the tool supports strategy, concepts, scenarios, governance, and the daily operating model of the BA practice.
An operations background is not a detour from architecture; it can supply the consequences, constraints, and institutional realism that abstract models lack.
A small, linked architecture package can outperform a comprehensive repository when it is designed around a real decision.
How to limit scope, avoid gold plating, and deliver a narrow but complete first release tied to measurable business value.
Practical guidance for establishing a small business architecture practice, building an initial capability, value stream, organization, and information baseline, and using it to support real business decisions.
What business architects should do when timelines stall, sponsorship weakens, execution never arrives, or business architecture is positioned only as the front door to a larger architecture pipeline.
The discipline becomes difficult at the boundaries: choosing the right abstraction, linking domains, and making architecture matter to a decision.
The Guild’s public landing page for introductory material, white papers, and other openly available resources.
A direct public PDF introducing the discipline, framework, core domains, and intended use of business architecture.
The public glossary for checking formal definitions and avoiding the near-synonym problem that makes BA difficult to learn.
A concise public paper distinguishing business architecture from process work, solution design, and organization charts.
An index of public papers covering alignment, governance, metrics, organization design, risk, and related practice topics.
The official OMG landing page for BACM, useful for understanding the formal relationships among business architecture concepts.
The full public specification for the Business Architecture Core Metamodel.
The OMG standard for ends, means, influencers, assessments, and directives that can anchor strategy mapping.
A public introduction to the Business Model Canvas; useful when BA work must begin above the capability layer.
A public guide for clarifying customer jobs, pains, gains, and the value proposition before translating them into architecture.
A public white paper on linking business architecture to measurable performance rather than stopping at maps.
A practical introductory video from the Business Architecture Guild on capability mapping.
A public explanation of capability maps, common structures, and practical examples.
A second public treatment of capability mapping that is useful for comparing terminology and modeling choices.
A public paper on using architecture to inform organization design without collapsing capability into the org chart.
Public federal service, function, data, and standards models that provide useful reference-model examples in Excel and JSON.
A public white paper on linking risks to business architecture so risk conversations become traceable and decision-relevant.
The GAO maturity framework offers a rigorous public example of staged governance, institutionalization, and management controls.
Public presentation material showing how practitioners frame scenarios, artifacts, and outcomes.
A public paper on maintaining business direction while working with application, data, solution, and technology architecture.
The official BPMN standard page. Use it to keep process notation distinct from value streams and capability models.
Public ASQ guidance on quality tools that complement BA when the work moves from structural diagnosis into root-cause analysis.
A public overview of cross-industry and industry process frameworks. Useful as a comparison point, not as a capability map substitute.
A free desktop tool for ArchiMate modeling and repository-based architecture work.
Public examples, guidance, scripts, and community resources for the Archi tool.
A free browser-based BPMN modeler for lightweight process work without installing a tool.
A free general-purpose diagramming tool for workshops, early models, and stakeholder communication.
The official public blueprint for the ten Certified Business Architect exam domains and their objectives.
Official public program policies covering membership, certification duration, retakes, and administration.
The Open Group’s current overview of the experience-based Open CA program and its three levels.
The official requirements document for experience, competencies, professional development, and contribution.
Official guidance for writing coherent, evidence-based experience profiles around real work and professional judgment.
A downloadable Markdown kit containing an engagement brief, capability canvas, value-stream card, impact grid, and review checklist.
A lightweight working charter for establishing a BA practice’s mandate, boundaries, decision rights, engagement model, first 90 days, and measures.
A practical study sequence built around one integrated case, distinction drills, scenario practice, and an error log.
A BA-led, graph-first reference architecture for using governed business architecture knowledge in explainable decision support.
A practical 90-day workbook for a business architect to frame, govern, test, evaluate, and decide a bounded SCALE implementation.
A simple private record for mentoring goals, sessions, work reviewed, decisions, and progress evidence.
Try a broader business term, clear the content-type filter, or begin with the problem-based recipe finder.