Sidebar for IT Project Professionals
by Roger T. Burlton, Ronald G. Ross & John A. Zachman1

This Sidebar is dependent on The Business Agility
Manifesto for context and meaning.

~~~~~~

A. True Business Agility
1. True business agility depends on sustainable business change – not justsustainable development of software.
2. True business agility is measured not just by speed of response to requests,changes, or disruption, but also by the coherence of the response.
3. True business agility results only when all silos or product pipelines are
eliminated within value chains.

B. Self-Organizing Teams
1. Self-organizing teams and other agile organization schemes alone do not lead tobusiness agility.
2. Self-organizing teams are a means, not an end. They do not reduce, but rather
increase, the need for business strategy, value chain coherence, reuse of businessknowledge, and effective portfolio governance.

1 Acks to Gladys S.W. Lam for input to the content and organization of the Manifesto and to Sasha Aganova forshepherding the work through to completion.
© Business Rule Solutions, LLC. 2017.
1© Process Renewal Consulting Group (2015), Inc. 2017.
© John A. Zachman, Zachman International. 2017.
Permission is granted for unlimited reproduction and distribution of this document under the following conditions:(a) The copyrights and this permission notice are clearly included. (b) The work is clearly credited to its threeauthors. (c) No part of the document, including title, content, copyrights, and permission notice, is altered, abridged
or extended in any manner.

C. Customer Centricity
1. Customer centricity is crucial – but never the only business goal. Certain
business issues never go away including: trade-offs with other business goals,
total cost of ownership, compliance, unacceptable risk, and unaffordable cost.
2. The true business customer is the business product customer – not the software
product owner.
3. Around business people, ‘customer’ should always mean business customer and‘product’ should always mean business product.
4. Users aren’t necessarily customers; user experience is not necessarily customer
experience. Customer experience should predominate.
5. Excellent customer experience encompasses all touch points with customers, notjust digital ones.

D. Failing Fast
1. Failing expensively or repeatedly, even if fast, is nonetheless waste to beeliminated.
2. The value of failing fast in order to learn fast must be balanced against otherfactors including: impact on business customers, cost of rework, and exposure torisk.

E. Communication
1. Relying solely on face-to-face conversations to convey and preserve businessknowledge is highly risky.
2. Effective communication of business knowledge over time – its retention – isinvaluable. It is far more difficult than simply closing communication gaps onprojects.

23. A critical skill for analysts is the ability to engage in dialogs to assess businessknowledge for gaps, conflicts, ambiguity, and completeness.

F. Change
1. Instantaneous change is not the goal. The goal is well-considered change that
achieves the desired business effect and avoids unintended side effects.
2. Frictionless change is not the goal. The goal is change that is dependably shaped
according to business strategy, policies, and business obligations andcommitments obligations.
3. Intimate, one-off change is not the goal. The goal is scalable, sustainable change.

G. Existing Lines of Business
1. Skimping on the quality of business software – creating a tech debt – has no placein businesses striving for change in existing lines of business.
2. In existing lines of business, self-organizing software development teams
contribute to business agility only if they build on, and contribute to, explicit
shared business knowledge.
3. In existing lines of business, time-to-market is directly dependent onreconfiguration agility.

H. Concept Models
1. The focus of a concept model is on what words you should use whencommunicating about the business, especially in writing and other business
communication, and on what those words mean.
2. The things in a concept model do not represent things in the real world; they
represent the business’s shared understanding of those things, as expressed inbusiness definitions.

33. The connections in a concept model indicate how concepts logically (i.e.,structurally) relate to one another.
4. A concept model is represented by a structured business vocabulary, including
both nouns and verb phrases.
5. A data model, class diagram or entity-relationship diagram is not a concept
model. Neither is a process model, use case, or an activity diagram.

I. Business Rules
1. Effective expression of business rules requires a concept model.
2. Business is grounded in contractual obligations and commitments, which can beviolated but with personal or business consequences.
3. Once business rules are encoded procedurally, semantics are lost that cannot beresurrected automatically. The loss renders business intent unclear and reuse
impossible.

J. Software Design and Development
1. Business agility cannot be achieved through agile software practices alone.
2. Rapid production of software tends to sub-optimize subsequent rapid costeffective modification of business knowledge.
3. User stories, use cases, and software prototypes can easily miss much of thebusiness knowledge needed for a holistic, effective and changeable businesssolution.
4. Certain things cannot be rank-ordered against software feature priorities
including: fidelity to contractual obligations and commitments, fit in the value
chain, and re-use of explicit business knowledge.
5. A software strategy that fails to capture, retain and reuse business knowledge ispoorly suited for the knowledge economy.

4