A Bushido Approach June 2018 EQE Team What We A re G oing T o Do T oday See A nother PPT Architecture what is it How do we see it at Wells Fargo Laws and pillars Examples and exercises ID: 788912
Download The PPT/PDF document "JITA - Just In Time Architecture" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
JITA - Just In Time Architecture
A Bushido Approach
June 2018
EQE Team
Slide2What We Are Going T
o Do Today, See Another PPT?Architecture what is it?
How do we see it at Wells Fargo?Laws and pillars
Examples and exercises
Having some fun
This is NOT a Power
P
oint Presentation (), it is a training reference booklet that I hope you will kept and review regularly. Like any Martial Art, doing it once is useless, as Bruce Lee said: “Do not fear the one that does a thousand punches once, fear the one that has done one punch a thousand times…. “So for today, I will ask you to: “Be Water, my friend”So let’s talk about it:
Slide3Architecture Bushido?
Proper architecture is like water:always evolvingadapting and ever changing
knowledgeable about the past understanding of the present needs
foreseeing future
potential
By nature, an architect must know a lot, but must also learn and adapt even more as they get into the process.
Similar to any traditional Martial
A
rt, an architect must train for years (following ShuHaRi principals). The goal of any dedicated Martial Artist is the shortest execution between two points for the most efficient defense/kill, and it should be likewise for an architect.Let’s listen why Architecture is Karate: https://www.youtube.com/watch?v=joNkScVrBhM
Slide4The Architect Bushido Way: ShuHaRi
In any traditional Martial Art, a master is not born, but trained, following the ShuHaRi path, not unlike the journey of an architect:Shu:
In this beginning stage the student follows the teachings of one master precisely, concentrating on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, the student concentrates on just the one way
that the master teaches.
Ha:
At this point
students begin
to branch out. With the basic practices
working, they now start to learn the underlying principles and theory behind the technique. They also start learning from other masters and integrate that learning into their practice.Ri: Now the students are no longer learning from other people, but from their own practice. They create their own approaches and adapt what they have learned to their own particular circumstances
.
As an architect, you must have been a developer, a tester, a DBA, a support FTE, and touched Audit and Risk as well as having been an HW manager at some point in your career.
Slide5What is Architecture all about, really?
Solution and Enterprise Architecture have evolved over the years and is necessary to enforce Connection, Cohesion and Changeability
to focus on what to do and how to position architecture in the organization.JITA (Just In Time Architecture) has two main goals:
Value creation / orientation (
Value vs. Waste)
Operational
excellence / optimization of work
processes (
Shorten Lead Time) These drive overall Waste reduction and optimization of Speed to Market, and the elimination of:Muda - that which is non-value adding or unproductiveMura - that increase inconsistency and ineffective communication
Slide6What is an Architect, Really?
The days of the ivory tower architects are dead, may they rest in peace, as are the days of full ahead-of-time architecture.
Architects are a very special kind of people that are fundamentally:Jacks of all trades
Love to speak and share
Are excellent listeners
T
eachers at heart
Today an Architect must exemplify
three driving factors in all work and projects:Successful Architect embrace the three Cs: Connection, Cohesion, and Changeability
Slide7The Three Cs: Connection, Cohesion and Changeability
Architecture is just a means that must add visible value. To do that, the EA and SA must at (their own level) focus on:
Connection to the organizational goals:Business goals
Projects goals
In summary, Architects do have a role and responsibility
to
understand the business aims and
ambitions and articulate it to all teams’ members
Cohesion to reduce cost and enhance speed of delivery must be achieved:By choosing from a limited number of solutions (reference architectures) to keep the complexity containedBy organizing the systems in a way that promotes sensible partitioning of functions and responsibilities, such that, simplicity and flexibility are increasedChangeability - the ability to adapt to rapid changes in business goals and the environments: By understanding and even forecasting changes, focusing on Changeability to reduce overall cost and increase long term viability
Slide8EA High Level View of future state at Wells Fargo
Enterprise Architecture is present to focus on the foundational patterns and best practices to be capitalized by the Solution Architects. Tech Fellows, who complement the EA groups, are aligned to the Domain as defined below and are responsible for:
Definition of the Best P
ractices for his/her
domain
Definition of
Main
tools / services
in supporting the domainGuidance and attendance at each ARB where their service is touched or impactedCapitalizing on System Thinking principals Implementation of
JITA
Slide9Never But Always …
Never
Always
Assume
Be 100% sure (just 99%)
Complicate things
Use unexplained acronyms
Keep a question to yourself
Stay still (water dies if still)Challenge yourselfMeasure yourself (and do not swing it)Learn more and be curiousRemember Pareto principle (80/20)Prioritize yourself first
Learn from recognized, proven patterns and create your own.
Look Internally and Externally:
DP, DEP codes
Clean architecture
NB: Please look here if link issue
https
://
8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
Slide10Thinking Toward a “Share Mental Model”
Slide11Ready to make money?
Who wants it?
Slide12Break 1
Slide13How do we do it at Wells Fargo?
First, we agreed on the Laws to follow, then the Principals of their implementation.
Second, we “just do it” enforcing the Lean philosophy. The 11 Senje’s
Laws of System T
hinking:
Today’s problem come from yesterday’s solutions
The harder you push, the harder the system pushes
back
Behavior grows better before it grows worseThe easy way out usually leads back inThe cure can be worse than the diseaseFaster is slowerCause and effect are not always closely related in time and spaceSmall changes can produce big results – but the areas of highest leverage are often the least obviousYou can have your cake and eat it too – but not all at onceDividing an elephant in half doesn’t produce two elephants
There is no blame
Exercise: FLOW at Wells Fargo
Slide14Break 2
Slide15The 11 Pillars of Just In Time Architecture
The principal of Lean / Just In Time Architecture allows all solution architects to provide maximum value to all project teams, reducing time to market to the minimum, while reducing risks and waste:Always
involvedTravel lightThink
Big, Act Small
All Hands on Deck early on
Just
in time, just enough
Iterative
Architecture DevelopmentArchitecture Initiated by Business GoalsFocus on the Value StreamComprehensible over comprehensivenessArchitecture emerging from ProjectsFreedom where possible, standardize where needed
Slide16Always Involved
Always involved means that architects are involved during the entire lifecycle of a project, from the initial inception of ideas up until (and including) when the deliverables of a project are in production.
The architects feel responsible for the business goals and are committed to deliver value to ensure
that the goals are
reachedArchitects support
multiple projects and constantly create alignment between stakeholders of all projects and
take
lessons learned
in projects into account, ensuring that others can learn from those lessonsWhat must happen:Both from the business and project sides, architects are fed with priorities and they can now make a balanced decision, from Business Architecture to Enterprise ArchitectureArchitects must speak face to face with team members a much as possible ( Audio call) NB: If problem with link, please use: https://youtu.be/DYu_bGbZiiQ
Slide17Travel Light
The principal is self explanatory: ‘Travel light’ should be taken literally; how much do architects
have to carry around, running from stakeholder to stakeholder? How much material do they need to explain the business needs to the development team? What do they need, in order
to explain the vision of the product to the business, to involve operations early,
etc…?
Reduce
the architecture of your IT systems to its
core essence
. Summarize the vision of the product into a few lines and some simple diagrams. Discuss these with the stakeholders, listen carefully to their feedback, and ensure that the architecture vision and diagrams of the IT systems are understandable by the business, operations, and project teams Think quality, not quantity, and reusable / federated minimum valuable documentation ONE Confluence page per project for high level, details as needed in children page that ALL participants can understandIt includes you; if you are a weight to the project, then change or find something else to do (Office Space)
NB: if problem
with
link use
https://
youtu.be/nV7u1VBhWCE
Slide18Think Big, Act Small
One of the main goals of an architect is to develop a vision of a system. It is
not the same as a design It is the general direction and boundaries for a system.
A design is a detailed description of the technical solution. The architectural vision encompasses more: from covering strategic directions to matching business
criteria.
During
implementation, the architect should
coach teams
in order to guide development. The architectural vision provides guidance for the general (technical) direction of the (sub-)projectsThe architect should choose the general architectural style of the system, and/or a set of general, high-level patterns. The implementation teams are then free to choose whatever design they see fit, within this general style Applying the “think big, act small” principle, it is better to introduce smaller sub-projects and give users time to gradually get used to the new production systemBe flexible and adapt (see the Zax)
NB: if
link
problem, please
use
https://
youtu.be/dZmZzGxGpSs
Slide19All Hands On
Deck Early OnThe essence of this principle is that all stakeholders of a project are involved at the start of the project. The architect role is crucial:
Use facilitation and social skills to keep the process progressing
Be willing to
challenge any points to increase the realm of brainstorming
P
revent
chaos
from taking over and record progressDrive proper summary, document collectively taken decisionsArchitect must be knowledgeable in all aspects of the projects (business, human factor, technical, and environmental, as well as cost and all aspect of testing and cost that will impact project DLC)An architect must be invited in the ideation and inception process as well as all subsequent steps of DLCThat assumes you know your stakeholders PERSONALLY
Slide20Just in Time
, Just Enough"Just in time, just enough
" to be able to speak with all stakeholders and decide what the next small steps must be.Decisions are made only when there is enough
knowledge available to
grasp the essence of an issue
If
not enough knowledge is available, then making the decision at another moment is a wiser choice most of the
time
Large scale project documentation creates waste and should be sunset in favor of ongoing discussion, decision-making, and right level documentation Architects must be able to define foundational decisions first (based on EA patterns) and evolve the project vision working within the DLC.Architects must be part of the DLC and participate as an equal with development teams (and / or be part of it)Make sure you are as brief and precise as possible and ALWAYS challenge yourself (Why do I need to say that? What is the value?)
Slide21Iterative Architecture Development
Architects must focus on: Defining and executing usable sub results (i.e., add value for the
business) by introducing iterations (Iteration is a process phase that, when finished, delivers a finished artifact)
Applying a Deming Cycle approach: Plan, Do, Check, Act
(or a variation of it: Speculate, Collaborate, Learn)
Defining
components
or subparts
that should be able to change over a number of iterationsAlways keeping the big picture in view (Think Big, Act Small) In line with any Agile / Lean principals, things are never finished and like a punch can always be made better; the trick is to be just good enough and willing to go back by small increment at it. Be like Jiro (Dream of Jiro)GAME : Marshmallow (https://www.youtube.com/watch?v=H0_yKBitO8M)NB: In case of link problem
for Jiro, please use
https://
youtu.be/R2L5IrkQTV0
Slide22Break 3
Slide23Architecture Initiated by Business Goals
Architects must remember that technology works for the business, and thus it is essential to:Understand what the business is aiming for and more importantly,
why they are aiming for thatCapture Vision
/ and its high level implementation in a limited set a slides
that can be discussed with and (very critically) understood by the business. If you cannot explain to the business why you're making certain decisions, then there's more work to
do
One efficient way is to think first in terms of Business Domains, not Technical Domains, and then execute the “bridging” which means:
Architects have a seat at the business project definition table
Architects must educate and gain trust in business community Architects are NOT BILLABLE to the project, but rather to the corporation
Slide24Focus on the Value Stream
Whatever does not bring real value should be eliminated:Start with your activities today: what have you done to add value to the value stream of your business, and
which of your activities can be considered wasteful?Find blockers and slow downs by using Queuing theories (System Thinking)
As the architect, always challenge the easy way in or out by applying proper leadership, and create trust with all stakeholder (use the 5 why techniques)
Understand all NFRs
including Audit and Risk Management corporate needs (ILM, SOX, Reporting …)
Know all your partners across all divisions
Understand the DLC and all necessary artifacts while always looking for way to reduce waste and increase Speed to Market
Slide25Comprehensible over Comprehensiveness
Documentation is important in architecture but you must remember that:
The prime objective of writing documentation is clear communicationCommunication is about
delivering a message to an audience
Any architectural document should provide just enough content
to "get the job done" and nothing more. The hard part is determining what is good
enough.
Remember quality over quantity and simplicity over anything else
Use your common sense to decide what is “good enough”, not based on what you think, but on feedback from stakeholdersDocumentation is never static and must be updated as knowledge progressThere is no one-size-fits-all, so be ready to adapt
Slide26Architecture Emerging
from ProjectsArchitecture in ivory towers is dead as it has/must evolve, and to evolve it needs feedback.A constant
feedback loop from the project and corporate groups is key to successEach new lesson / feedback might trigger
adjustment of earlier decisions and guidelines,
or refinement of the architecture vision
Not every lesson learned is related to an earlier architectural decision,
guideline,
or
vision and these lessons also have to be fed back to the rest of the organization. Architects must facilitate this spreading of the knowledge (mentor / teacher role)Architects must internally meet on a regular basis to share lessons learned and possible new best patterns and practicesArchitects can not have a one-size-fits-all mental modelsCI applies as much to code as it is to architecture (Architecture is meta-code). Always improve as explained by Dr Russ AckoffNB: If link does not work: https://youtu.be/OqEeIG8aPPk
Slide27Freedom where possible, standardize where needed
Water is free to go as it pleases BUT usually follows the best proven path. Similarly Architectural Standards should:Have a clear connection with the business goals
Result from best practices and experiences during projects
Be only concerned with
reducing complexity
Be reviewed on a
regular bases
to avoid becoming obsolete
Consider all aspects (not only technical but also cost, supportability, and Audit/Risk)Leave room for innovative ideas Be accompanied by the argumentation behind the standard in a clear and as easy as possible manner.Standards evolve and architects must regularly challenge themselves on the current validity of the standardArchitects must be familiar with standards and be willing to adapt them for a specific project without losing the vision behind the standard
Slide28Quoting the masters moving forward
Bruce Lee“Knowing is not enough; we must apply. Willing
is not enough; we must do.“Mark Twain“I never let schooling get in the way of my education.”
Henry Ford“If you think you can, or you think you can’t, you are right.”
Aristotle
“You are what you repeatedly do.”
Bruce Lee
“The successful warrior is the average man, just with laser-like focus.”
Slide29Next Steps
Define your success planDefine your priorities
Be prepared to become the trainer, so exercise and come back in weekly brown bag meetings with questions and success storiesParticipate in Architecture community
Slide30External References (Thanks to Ahmad
Fahmy)
On-Line References
Books
Unfreezing an organization (
Link
)
How to form teams at scale (
Link)The taxonomy of A-Holes (Link)Running an impact mapping session (Link)Kanban (Video)Lean (Site)Systems Thinking (Site)Theory of constraints (Video
)
ATDD & Spec By Example (
Video
)
Continuous Delivery (
Video
)
Scrum (
Guide
)
The Five Dysfunctions of a Team
(
Amazon
)(
video
)
The Phoenix Project
(
Amazon
)
The Fifth Discipline
(
Amazon
)
Specification by Example
(
Amazon
)(
Video
)
The Art of Learning
(
Amazon
)
Extreme Programming
(
Amazon
)
Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management
(
Amazon
)(
Video
)
Leading Teams
(
Amazon
)(
Video
)
Scaling Lean & Agile Development
(
Amazon
)
Lean Startup
(
Amazon
)(
Video
)