As architects , many of us have grown from highly technical positions
where our success was derived mainly from our ability to talk to machines.
However, in the role of architect much of our communication is now done with
our fellow human beings. Whether it’s talking to developers about the benefits
of employing a specific pattern, or explaining to management the cost-benefit
tradeoffs of buying middleware, communication is core to our success.
Architects Must know and undestand:
Everything Will Ultimately Fail
You’re Negotiating More Often Than You Think
Quantify
One Line of Working Code Is Worth 500 of Specification
There Is No One-Size-Fits- All Solution
It’s Never Too Early to Think About Performance
Architecting Is About Balancing
Commit-and- Run Is a Crime
There Can Be More Than One
Business Drives
Simplicity Before Generality, Use Before Reuse
Architects Must Be Hands On
Continuously Integrate
Avoid Scheduling Failures
Architectural Tradeoffs
Database As a Fortress
Use Uncertainty As a Driver
Warning: Problems in Mirror May Be Larger Than They Appear
Reuse Is About People and Education, Not Just Architecture
There Is No ‘I’ in Architecture
Get the 1,000- Foot View
Try Before Choosing
Understand the Business Domain
Programming Is an Act of Design
Give Developers Autonomy
Time Changes Everything
“Software Architect”Has Only Lowercase a’s; Deal with It
Scope Is the Enemy of Success
Value Stewardship Over Showmanship
Software Architecture Has EthicalConsequences
SkyscrapersAren’t Scalable
Heterogeneity Wins
It’s All About Performance
Engineer in the White Spaces
Talk the Talk
Context Is King
Dwarves, Elves, Wizards, and Kings
Learn from Architects of Buildings
Fight Repetition
Welcome to the Real World
Don’t Control, but Observe
Janus the Architect In the Roma n world, Janus was the god of beginnings and endings, doors
and passageways. Janus is usually depicted with two heads facing in different
directions, a symbol you may have seen on coins or in the movies. Janus
represents transitions and changes in life from past to future, young to old,
marriage, births, and coming of age.
Architects’ Focus Is on the Boundaries and Interfaces
Empower Developers
Record Your Rationale
Challenge Assumptions— Especially Your Own
Share Your Knowledge and Experiences
Pattern Pathology
Don’t Stretch the Architecture Metaphors
Focus on Application Support and Maintenance
Prepare to Pick Two
Prefer Principles, Axioms, and Analogies to Opinion and Taste
Start with a Walking Skeleton
It Is All About The Data
Make Sure the Simple Stuff Is Simple
Before Anything, an Architect Is a Developer
The ROI Variable
Your System Is Legacy; Design for It
If There Is Only One Solution, Get a Second Opinion
Understand the Impact of Change
You Have to Understand Hardware, Too
Shortcuts Now Are Paid Back with Interest Later
“Perfect” Is the Enemy of “Good Enough”
Avoid “Good Ideas”
Great Content Creates Great Systems
The Business Versus the Angry Architect
Stretch Key Dimensions to See What Breaks
If You Design It, You Should Be Able to Code It
A Rose by Any Other Name Will End Up As a Cabbage
Stable Problems Get High-Quality Solutions
It Takes Diligence
Take Responsibility for Your Decisions
Don’t Be Clever
Choose Your Weapons Carefully, Relinquish Them Reluctantly
Your Customer Is Not Your Customer
It Will Never Look Like That
Choose Frameworks That Play Well with Others
Make a Strong Business Case
Control the Data, Not Just the Code
Pay Down Your Technical Debt
Don’t Be a Problem Solver
Build Systems to Be Zuhanden During successful use, a tool is zuhanden (“ready-to-hand,” having the property
of “handiness”). The tool is experienced directly; it is used without consideration,
without theorisation. We grasp the tool and use it to move toward
our goal. In use, it vanishes! The tool becomes an extension of the user’s body
and is not experienced in its own right. One sign of a tool being zuhanden is
that it becomes invisible, unfelt, insignificant.
Find and Retain Passionate Problem Solvers
Software Doesn’t Really Exist
Learn a New Language
You Can’t Future-Proof Solutions
The User Acceptance Problem
The Importance of Consommé
For the End User, the Interface Is the System
Great Software Is Not Built, It Is Grown
ICT (information & communication technology) solutions for Governments
E-government solutions for Governments
IT and IT security solutions
Cyber security awareness raising, education and training programs
Cyber security policies and user behavior
Economics of cyber security
The role of end users on cyber security risks and their mitigation
The role of security, privacy and trust in human-computer interactions
Effects of security systems upon user, corporate, and governmental behavior
Usable security and privacy;
User acceptance of security policies and technologies;
User psychology and social influence in security and privacy decisions
User security and privacy by design
Public key infrastructure
Electronic identity and Documents
Mobile phone solutions for Governments
Centralized data management
Decentralized data management
Distributed data management
Best practices from Estonian e-government solutions (only working government in the world and over 15 year)
To be successful as a ICT architect You need to master all, Legalization, business and technology.
