“FLOW”: HIGH QUALITY EXPERIENCES

“FLOW” OR “HOW TO ACHIEVE HAPPINESS”  

The concept of “FLOW” was described by Professor Mihaly Csikszentmihalyi in his 1990 book (“FLOW”) after years of investigation at the Department of Psychology at the University of Chicago. The book was a best seller. Other books followed, applying the concept to specific areas, including business. You can find some lectures by Professor Csikszentmihalyi in YOUTUBE and other Internet sites. He was for some time the chairman of his Department and later on professor at the Drucker School of Management in California.   

At first sight, “FLOW” sounds like something you would hear from a funny sect or a miraculous technique you would hear about in the TV programs late at night. You can easily imagine the TV host, dressed as a wizard, in a set decorated with planets and horoscope symbols, lecturing about how to get into “flow”.

However, “FLOW” is a well-established concept, used extensively in Positive Psychology. You’ll find an article in the WIKIPEDIA (look for “Flow (psychology)”) and an iPhone App for measuring your flow states (“InFlow” by AITA Ltd). Several investigators in universities around the world have been investigating “flow” in various contexts. For getting a good understanding of the concept, it is necessary (in my opinion) to read Csikszentmihalyi’s book; reading a short description won’t do it. “FLOW” is one of those concepts that are at the same time simple and subtle, close to our knowledge space but at the same time difficult to define the boundaries. In his book, Csikszentmihalyi presents tenths of examples, with chapters dealing with the body (sports, etc.), intellectual activity, the workplace, social life, etc. After going through all those examples, you really get the idea.

The reason for writing a few articles about “FLOW” in this space is to explore its immediate, simple and extremely rewarding application to our work environments. I lived in the past years several situations in which I somehow “knew” we were doing wrong, with a wrong management framework. However, I could not really identify what was wrong, all I had were vague “feelings”. The concept of “FLOW” is invaluable for making sense of a number of these situations.  

WHAT IS “FLOW”? 

FLOW is an experience we all know quite well. Recall a few situations in which you were felt happy, and chances are you were experiencing FLOW. 

A few examples: 

• you were playing a disputed sports match for some time; it can be tennis, soccer, basketball, baseball, golf or any other sports; you were very concentrated and enjoying it a lot; time passed fast, you couldn’t believe you had been playing for longer than two hours (much longer, if golf)  

• at work, you were dealing with a sales operation that became more and more difficult; the customer presented several last time conditions; your team didn’t know how to deal with them; you had to figure out new solutions and you had the deadline just ahead; you had to stretch your best skills; in the end, you were proud of the final result – much better than you had imagined in the beginning 

• you are a student, at any level; in September, you see an area as particularly difficult (it could be Maths, French, Introduction to Quantum Mechanics or Introduction to Heidegger’s Philosophy). You dedicate time and effort to it – and it takes you a lot - and you have good progress. By May, you have mastered the area and are quite comfortable teaching your colleagues. 

• you are taking care of your baby; she is learning how to walk and she is saying her first words; you enjoy spending your time with her, it is the best time of the day; time goes by and you do not notice it; you both are smiling almost all the time 

• a musician is playing the piano; he feels challenged by a particularly difficult piece of music; he spends days practicing and figuring out how to best play some parts; after a lot of effort, he can play the whole piece without errors; while playing, he feels his hands go over the keyboard by themselves – he feels he is in “FLOW”  

Csikszentmihalyi used the word FLOW for naming his concept after the word appeared many times in the descriptions of positive experiences provided by several artists and sportsmen he were observing.

In the next article: definition of FLOW.

[END]

MOM, DAD AND THE EMOTIONAL INTELLIGENCE

OUR PARENTS AND THE EMOTIONAL INTELLIGENCE    

If you are older than 30, your parents almost certainly didn’t know about “emotional intelligence” while they were educating you – unless they were psychologists and were following the discussions triggered by Howard Gardner (from Harvard University) in 1983, after the publication of his book “Frames of Mind: The Theory of Multiple Intelligences”. 

“Emotional Intelligence” reached the general public in 1995. Daniel Goleman’s best seller « Emotional Intelligence – Why it can matter more than IQ » combined the work of tenths of investigators in Psychology, presenting their results in an integrated and meaningful way, accessible to us, lay people. The core concept of emotional intelligence was taken from Peter Salovey (Yale University) and John D. Mayer (University of New Hampshire). Seventeen years later, Goleman’s book is still an authoritative reference in the matter, quoted by anyone who writes about Emotional Intelligence. 

WHAT MOM AND DAD TAUGHT US  

The people I know better belong to two groups, in two countries with remarkable differences. Yet, several of the key messages I received from my parents are shared with both groups.

A few of the values and behaviour models Mom and Dad taught me:

• "Cultivate good feelings and fight the bad ones" 
• As good persons we are, bad feelings are unwelcome. Lifetime is too precious for wasting it with anger, fear, envy, lust and other bad feelings. 
• Bad feelings should be suppressed. 

• "Be « noble » and altruist, display your best face to the world"  
• Don’t pay too much attention to your feelings; if you do, you become selfish and self-indulgent.  
• Whether you feel tired, bored, fearful, anxious, etc., keep it to yourself. Your friends and mates do not have to be bothered with your ugly side. 
• We must give precedence to other people’s needs; our own needs come second or third. 

• "Children do never think bad of their parents and other key reference people" 
• Don’t ever feel angry or be disrespectful with them – that’s more than ugly. 
• Don’t have « inappropriate » feelings (such as sensual attraction towards a beautiful aunt). 

• "Don’t tell me you are feeling down, depressed; be a man!" 
• “Depression? What is that? At your age, I had already achieved a lot, under much worse conditions”.  

• "Life is hard work – don’t expect too much enjoyment" 
• Life is hard work. If you are having fun, better for you; yet, not having fun is not an excuse for not doing what has to be done. 
• That applies to jobs, marriage and child rearing. 

• "When dealing with other people, don’t manipulate, be spontaneous" 
• The only right way of dealing with friends and acquaintances is to act naturally. 
• People who do it differently become hypocrites. 

• "Outbursts of rage are positive" 
• An enraged man or woman is acting with authenticity. 
• It is good to have an outburst of rage from time to time (provided it does not end in aggression, of course). It proves you are sincere and committed. 
• When things get confuse, an outburst of rage can put things in their places.   

And so on. Add to that a set of strict rules applying to the sex realm and we all get the picture. Most heroes we admired in the movies behave in accordance with this model.

There is nothing fundamentally wrong with these values and models. We can rear our children following the same ideas. The issue is that our parents raised us before the current knowledge around «Emotional Intelligence» was available to the general public. As a consequence, the “implementation details” of our education sometimes made us not so smart, in the Emotional Intelligence domain. 

EMOTIONAL INTELLIGENCE (IN A FEW PARAGRAPHS) 

The model adopted and made popular by Daniel Goleman defines Emotional Intelligence as the combination of 5 skill domains:

1 – Self-awareness

2 – Self-management

3 – Self-mastery  

4 – Empathy

5 – Social arts 

Figure 1 – The emotional intelligence skill sets. 

SELF-AWARENESS

« Recognizing a feeling as it happens is the keystone of emotional intelligence. An inability to notice our true feelings leaves us at their mercy. People with greater certainty about their feelings are better pilots of their lives. «   

SELF-MANAGEMENT

The skills that allow us to avoid « emotional hijacks » by anger, anxiety or depression.

« The capacity to soothe oneself, to shake off rampant anxiety, gloom or irritability. »

« People who are poor in this ability are constantly battling feelings of distress, while those who excel in it bounce back far more quickly from life’s setbacks and upsets. »

SELF-MASTERY  

The ability to « marshal emotions in the service of a goal ».

Being able to keep an optimistic state of mind despite of setbacks.

Being able to go into the « flow » state that takes one to optimal and gratifying experiences and to high performance.

EMPATHY

The ability to recognize emotions in others.

Self-management is a pre-requisite for empathy; a person under « emotional hijack » does not have enough « working space » left in his mind for exercising empathy.

SOCIAL ARTS (HANDLING RELATIONSHIPS)  

The ability to manage emotions in others.

The ability to act taking into account the emotions of our mates.

Picture a group of highly « emotional intelligent » people. What do you see?  

• They are constantly monitoring their emotional reactions to whatever they go through, in the same way a physician or a psychotherapist is always monitoring his reactions to whatever their patients say. 
• In a sports game, a defense player won’t allow a player of the other team to move around without careful monitoring; in the same way, the emotional intelligent person is always monitoring her/his own feelings. A feeling that is moving around unattended (such as an outburst of anger) can produce undesirable reactions.  
• They actively act upon feelings that can escalate in intensity and lead to an « emotional hijack », be them anger, anxiety or sadness. They do never repress or hide such feelings from themselves, but they are always in control. They do not allow strong feelings to “overflow” and blur their conscience.  
• Sometimes you see they are angry; however, they are always able to manage the energy released by their anger. And sometimes you see they become anxious or sad; however, they are able to prevent such moods to escalate and they recover after a short while.   
• They show most of the time strong motivation for what they are doing. That is because they know how to marshal their psychic energy and apply it to the task they are committed to.  
• They are constantly aware of the feelings and concerns of the people around them. They actively invest psychic energy in uncovering other people’s feelings and concerns.  
• They are excellent at « active listening ».  
• They are good at the « social arts ». They know how to use other people’s feelings in « win-win » arrangements. They are good at creating bonds with other people.

HOW DOES « EMOTIONAL INTELLIGENCE » MISMATCH OUR PARENTS’ TEACHINGS 

The way I implemented Mom and Dad’s teachings conflicted with the skill sets of emotional intelligence. I’ve seen the same conflict in friends and acquaintances.

SELF-AWARENESS (the basis of emotional intelligence):

Conflicts with several of Mom and Dad messages: 

-        Fight and hide the bad feelings  

-        Do not spend too much time considering yourself – particularly your feelings (“don’t be selfish!”)

-        Children do never think bad things of their parents and other reference people  

-        Don’t tell me you are feeling down, depressed; be a man!

Mom and Dad’s teachings do not stimulate the practice of self-awareness.

SELF-MANAGEMENT and SELF-MASTERY: 

Conflict with the ideas that

- Outbursts of rage are positive 

- An enraged man or woman is authentic

- "Life is hard work – don’t expect too much enjoyment" 

In my child environment, if you don’t “let go” your anger from time to time, you are not acting naturally. If somebody “pushed your buttons”, you were obliged to strike back. If you didn’t, you were not doing well – something was wrong with you.

Mom and Dad’s teachings do not rule out “emotional hijacks”; they even stimulate them, in moderate doses.

And looking for "enjoyment" at work or even in the marriage is not to be admired. One does what has to be done, full stop. 

EMPATHY: 

Inherits the negative view of giving too much attention to own feelings.

Mom and Dad’s teachings say that whoever demands this kind of attention is not to be admired. He is selfish and self-indulgent, so better not to spend too much attention on him.

Besides, “empathy” is a woman’s thing; men do not care about empathy.

SOCIAL ARTS: 

Conflict with the idea that 

-        When dealing with other people, one must not manipulate and must be spontaneous

Mom and Dad’s teachings say that one should not dedicate energy to purposefully knowing other people’s emotional patterns. Only “bad people”, such as politicians, do such things.

Mom and Dad’s teachings provide us the ethical grounding and warmth we build our life upon. They only have to be updated and adjusted, in order to become fully compatible with the skill sets of the emotional intelligence we need to be more successful in the Internet era.

[END]

ARCHITECTURE MATURITY MODEL ("CRIB NOTES")

Architecture Maturity Model   

In the past years, the Capability Maturity Models have been extensively used by many organizations, for assessing their status and guiding the improvement of their IT related processes, mainly in the software and systems engineering areas.

« Such models provide the following benefits :

• They describe the practices that any organization must perform in order to improve its processes
• They provide a yardstick against which to periodically measure improvement
• They constitute a proven framework within which to manage the improvement efforts

The various practices are typically organized into five levels, each level representing an increased ability to control and manage the development environment. »

TOGAF 9 does not provide an « official » Maturity Model for Enterprise Architecture. It does provide, however, a quite detailed example, taken from the US Department of Commerce.

US DoC Architecture Maturity Model  

The DoC ACMM consists of six maturity levels and nine architecture elements.

The six levels are :

0 – none

1 – initial

2 – under development

3 – defined

4 – managed

5 – measured

The nine enterprise architecture elements are 

• architecture process 
• architecture development 
• business linkage 
• senior management involvement 
• operating unit participation 
• architecture communication 
• IT security 
• architecture governance 
• IT investment and acquisition strategy   

The table below describes in a brief way the maturity levels 1 to 5. Level 0 means « no enterprise architecture program ; no enterprise architecture to talk about. »  

Enterprise  Architecture Aspect	Level 1: INITIAL	Level 2: UNDER DEVELOPMENT	Level 3: DEFINED	Level 4: MANAGED	Level 5:  MEASURED
architecture process	Ad hoc; dependence on individual efforts ("heroes").	Clear roles and responsibilities are defined	EA process is largely followed	EA process is part of the culture. Quality metrics are captured.	EA process is under constant improvement effort
architecture development	Ad hoc, localized	Vision; principles; baseline and target architecture; TRM; standards framework	Gap analysis and migration plan are completed. Standards profile is fully developed	EA documentation is regularly updated. All architectures comply to standards.	Standards and waivers process encompasses all IT decisions
business linkage	Minimal	Explicit linkage to business strategies	EA integrated with CAPEX and investment control	CAPEX and investment control take EA as key input. Periodic re-examination of business drivers.	Business is involved in the continuous EA process improvement
senior management involvement	Minimal	Senior management is aware of EA effort	Senior management actively supports EA process and standards	Senior management directly involved in EA review process.	Senior management is involved in the continuous EA process improvement
operating unit participation	Minimal	Clear roles and responsibilities are defined	Most elements support and actively participate in EA process	The entire unit supports and actively participates in EA process	Feedback from unit drives EA process improvement
architecture communication	Documentation is on the web	Related web pages are kept up to date with EA deliverables	EA own web pages; they are kept up to date with EA deliverables	EA documentation is regularly updated	Architecture documentation is used by every decision maker in IT
IT security	Ad hoc, localized	Clear roles and responsibilities are defined	IT security architecture standards profile fully developed	Performance metrics are captured	Feedback from IT secutiry drives EA process improvement
architecture governance	No governance	Some adherence to existing standards profile	Explicit governance of majority of IT investments	Explicit governance of all IT investments	Standards and waivers process encompasses all IT decisions
IT investment and acquisition strategy	Minimal participation of EA	Some adherence to existing standards profile	IT acquisition strategy complies with EA; cost benefit analysis of projects	All planned IT acquisitions are governed by EA	No unplanned IT investment or acquisition activity

TOGAF ARCHITECTURE CONTENT FRAMEWORK ("CRIB NOTES")

TOGAF Architecture Content Framework

Architecture development is under way. Wev’e got the architecture capability up and running. The architects are working on a number of engagements, applying the best of their skills and energy.

What will their work products look like ?

A few well known architecture frameworks deal with the enterprise architecture content domain. The Zachmann Framework and UK Ministry of Defense MODAF are two good examples. These frameworks have some material related to methodology and governance, but they concentrate primarily on the organization of the outcomes of the work products generated by the architects.  

TOGAF’s authors (The Open Group Architecture Forum) have dedicated a rich section of TOGAF to the organization and « framing » of the work products generated by the architecture team. TOGAF’s approach is based on real practice, kind of « bottom up ». Most enterprise architecture practitioners will immediately feel familiar with the organization of the contents proposed by TOGAF, even if they have been using a different framework or no framework at all, only his common sense.

TOGAF’s approach to Architecture Content is based on the following ideas : 

• The set of objects (« building blocks ») the enterprise architect deals with is limited and can be fully described in a model. This is the Content Metamodel.
• The Content Metamodel has to be flexible, in order to adjust to the different contexts found in the organizations.
• The architects produce « deliverables » and describe the « building blocks » (for sure !). However, they aren’t the only products that have to be managed. In order to reach effectiveness and efficiency, the intermediate, more atomic « artifacts » generated by the architecture work have to be managed as well. The artifacts have higher reusability than the final deliverables and building blocks.
• The enterprise architecture content represents the whole organization, and that is too much information. In order to get effective communication with the stakeholders and participants, the architecture contents has to presented in « views » that address the particular concerns of each interest group.  

« A TOGAF architecture is based on defining a number of architectural building blocks within architecture catalogs, specifying the relationships between those building blocks in architecture matrices and then presenting communication diagrams that show in a precise and concise way what the architecture is. »

The figure reproduced below depicts in a diagram the key roles that take part in the TOGAF Architecture Content Framework.  

TOGAF CONTENT METAMODEL - OVERVIEW

TOGAF Architecture Content Metamodel  

« The content metamodel provides a definition of all the types of building blocks that may exist within an architecture ». (« Building blocks » are presented below. If you are thinking of LEGO blocks, you are right. Business functions, data entities, application components and technology components are examples of building block categories.)

We’ve already seen that, while executing an ADM engagement, the architecture team will : 

• Define a « vision » for the engagement 
• Manage the requirements identified by architecture 
• Define the baseline architecture and the target architecture, for the four domains : business, data, applications and technology 
• Define the work packages, projects and programs to the executed 
• Govern the execution of those projects and programs 

The Architecture Content Metamodel presents the structured set of objects (or « building blocks ») that is generated by the architects executing the ADM. « The ADM describes what needs to be done to create an architecture and the content framework describes what the architecture should look like once it is done. »

TOGAF’s authors have created a metamodel made up of 32 entities. Minor inconsistencies among parts of the text reveal the intensity of the debate before reaching the current result. A few aspects of the metamodel are not completely clear. The final result is definitely invaluable for the enterprise architect. 

TOGAF Architecture Content Metamodel is a detailed data model, encompassing the 32 entities, their respective attributes and the relationships among them. Any enterprise architecture should fit in TOGAF content metamodel.

The figure reproduced below presents an overview of the TOGAF Architecture Content Metamodel.

TOGAF ARCHITECTURE CONTENT METAMODEL

The figure reproduced below presents the entity-relationship view of the full metamodel.

CONTENT METAMODEL - ENTITY-RELATIONSHIP VIEW

TOGAF Architecture Content Metamodel : Core Content and Extensions   

There is no « onse size fits all » in enterprise architecture. Each organization, in each phase, has a different context for the enterprise architecture engagements. Budget and time restrictions might impose restrictions on the scope.

A few examples of variable conditions that might apply : 

• The business drivers might be fully defined or they might be a rough draft  
• Business processes might be fully modeled, or their modeling might be out of scope 
• Services (meaning a Services Oriented Architecture) might be key to the modelling, or they might be not considered at all 
• Technology domain might be a key concern, or it might be out of scope

Other architecture content frameworks intended for specific organizations are very specific in their modeling of objects. This is the case with MODAF (intended for use in the UK Ministry of Defense) and DODAF (intented for use in the US Department of Defense). TOGAF is intended to be used by any kind of organization ; how to cope with the range of different contexts ?

The solution proposed by TOGAF is to structure the metamodel object types in a few groups. There is a « core » set of objects that are required in all contexts. To this core, a few optional groups can be added. If all optional groups were added, we’d get the complete model we’ve seen above.

One gets the feeling that the resulting grouping is not completely « natural », meaning that if the exercise of grouping the entities were repeated by a different work group, the result might have been different. Anyway, it is an excellent model to follow.

The picture reproduced below represents the core content metamodel and the six extensions.

TOGAF CONTENT METAMODEL - CORE AND EXTENSIONS

TOGAF’s architecture core content metamodel is made up of 17 entities. The remaining 15 entities (the full metamodel is made up of 32 entities) are distributed in the 6 optional extensions.

The 17 entities TOGAF authors consider mandatory in order to build an enterprise architecture are identified in the picture reproduced below. 

TOGAF CORE CONTENT METAMODEL

It stands to reason that the majority of the mandatory, « non negotiable » entities in the metamodel are the ones that make up the foundation of the architecture function and the ones that reflect the business domain. The 15 entities that are classified as « extensions » add detail to the description of the resulting architecture in the four domains (business, data, applications and technology).

TOGAF Architecture Content : Artifacts and Views 

The architects produce « deliverables » and « building blocks ». However, these products are the final outcomes and too coarse-grained to allow optimum content management. Before assemblying them, the architects produce a whole lot of more atomic work products, called « artifacts ».

An « artifact » is a piece of documentation that captures any aspect of the system analyzed by the architect and that is relevant to his work. While working on an existing or on a new system, the architect will deal with a whole lot of viewpoints, information and stakeholders ; he will have to: 

• Document aspects and components of the current system that are relevant to him, without getting lost in too much detail  
• Understand and document relatioships between aspects and components of the current system 
• Capture facts and scenarios, in order to present them to the stakeholders and participants 
• Detail to some degree the future scenarios 
• Describe aspects and components of the target solution (again, without getting lost in details 
• Understand and document relatioships between aspects and components of the target system 
• Convince all of the stakeholders of the quality of his ideas, talking to each one in his own language and addressing the concerns of his viewpoint 
• Relate his ideas to the company’s objectives

TOGAF Content Framework identifies a set of artifacts that typically is generated by the architects’ work. The artifacts are also called « viewpoints ». The combination of viewpoints make up the views of the architecture.

Three classes of artifacts are generated : 

• Lists 
• Matrices 
• Diagrams 

The picture reproduced below represents the artifacts (or « viewpoints ») identified in TOGAF.

TOGAF CONTENT METAMODEL - ARTIFACTS

Combinations of artifacts allow the architects to tackle the concerns of all of the atakeholders, each one of them requiring a specific view of the solution. The following views are identified in TOGAF. Additional views will be added, depending on the nature of the architecture being developed. 

• Business architecture view 
• Enterprise security view 
• Software engineering view 
• System engineering view 
• Communications engineering view 
• Data flow view 
• Enterprise manageability view 
• Acquirer view

TOGAF Architecture Content : Deliverables 

TOGAF proposes a taxonomy of deliverables that are typically produced during the execution of the ADM cycle. For each one, TOGAF describes the general organization and provides an elaborated template.

The deliverables enumerated by TOGAF are listed below. They are grouped by the ADM phases in which they are produced.

During the customization of TOGAF for a specific organization, the templates have to be extended and detailed ; a deliverable such as « Architecture Definition Document » can include just about any contents.

• ADM Preliminary Phase  
• Business Principles, Business Goals, and Business Drivers  
• Architecture Principles  
• Tailored Architecture Framework  
• Request for Architecture Work  
• Organizational Model for Enterprise Architecture  
• Architecture Repository  
• Phase A: Architecture Vision 
• Statement of Architecture Work  
• Capability Assessment  
• Architecture Vision  
• Communications Plan  
• Phase B: Business Architecture 
• Phase C: Information Systems Architectures — Data Architecture 
• Phase C: Information Systems Architectures — Application Architecture 
• Phase D: Technology Architecture 
• Architecture Definition Document 
• Architecture Roadmap  
• Architecture Requirements Specification  
• Phase E: Opportunities & Solutions  
• Statement of Architecture Work  
• Phase F: Migration Planning  
• Implementation Governance Model  
• Architecture Contract 
• Architecture Building Blocks 
• Phase G: Implementation Governance  
• Solution Building Blocks  
• Compliance Assessment 
• Phase H: Architecture Change Management  
• Change Request 
• Requirements Impact Assessment 
• ADM Architecture Requirements Management  
• Architecture Requirements Specification 

TOGAF Architecture Content : Building Blocks 

« An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.

The building blocks in an architecture specify the scope and approach that will be used to address a specific business problem. »

In other words, an « architecture description » is a model that :  

• identifies all of the building blocks in all of the categories in the Architecture Content Metamodel (17 categories, if only the core model is used ; 32 categories, if all of the extensions are used) : 
• all of the actors and roles
• all of the functions and processes
• all of the business services
• all of the application components
• all of the technology components
• etc.
• identifies all relationships between those building blocks
• describes each building block and each relationship in enough detail
• represents the set of building blocks and relationships in ways that can be understood by the stakeholders 

« Building blocks have generic characteristics as follows:

• A building block is a package of functionality defined to meet the business needs across an organization.
• A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)
• A building block has a defined boundary and is generally recognizable as « a thing » by domain experts.
• A building block may interoperate with other, interdependent, building blocks.
• A good building block has the following characteristics:
• It considers implementation and usage, and evolves to exploit technology and standards.
• It may be assembled from other building blocks. 
• It may be a subassembly of other building blocks.
• Ideally a building block is re-usable and replaceable, and well specified. »

The definition of the set of building blocks that make up an architecture is developed in two phases: 

• Architecture building blocks (ABBs) in phases A to F 
• Solution building blocks (SBBs) in phase G

« ABBs:

• Capture architecture requirements; e.g. business, data, application and technology requirements
• Direct and guide the development of SBBs »

“SBBs:

• Define what products and components will implement the functionality
• Define the implementation
• Fulfil business requirements
• Are product or vendor-aware”

Typically, several ABBs map to SBBs in a obvious way, that will be promptly identified by the architects and stakeholders.

The target architecture typically reuses to the maximum extent the building blocks already present in the baseline architecture. 

The picture reproduced below describes how the building blocks are developed during the ADM. 

TOGAF ADM AND THE "BUILDING BLOCKS"

[END OF POST]