Technics Publications

Principle Based Enterprise Architecture

$39.95
$79.95

Principle Based Enterprise Architecture: A Systematic Approach to Enterprise Architecture and Governance, by Ian Koenig

The Principle Based Enterprise Architecture (PBEA) Method is a proven approach for implementing an enterprise-wide architecture practice in large- and medium-sized technology organizations.

Topics

PART I: The Principle Based Enterprise Architecture (PBEA) Method

Chapter 1: Context

Objectives
Solutions
Placement of Function (PoF)
Environments


Chapter 2: Assets

System assets
Data Assets
Software assets
Infrastructure assets
The art of versioning


Chapter 3: Program Increments


Chapter 4: Roles

Product owner
Business capability owner
Technology owner
Asset owner
Technical architect
Enterprise architect
Solution architect


Chapter 5: An Example – νNews (Pronounced: Nu News)


Chapter 6: Architecture Governance

Asset governance
API governance
Software asset governance


Chapter 7: Architecture Metrics

The Asset Checklist
Technical debt and architecture debt
Outcomes and the ‘body of evidence’


Chapter 8: Best Practices and Processes

Inventories and registries
Patterns
Architecture diagramming
Architecting testable solutions
Architecting secure and compliant solutions
Architecting responsive solutions
Operational practice
Monitoring practice
Graceful degradation of service


Chapter 9: Change Management

Golden rule evolution
Root cause analysis (Why? Why? Why?)
Technology standard evolution


Chapter 10: Getting Started with PBEA

Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12


PART II: PBEA Architecture Objectives, Principles, and Golden Rules

Chapter 11: Architecture Principles


Chapter 12: Architecture Golden Rules


Chapter 13: Architecture Objectives for Systems

Safe solutions
Responsive solutions
Effective solutions


Chapter 14: Architecture Objectives for Data

Safe solutions
Responsive solutions
Effective solutions


Chapter 15: Asset Principles and Golden Rules

Secure systems (safe solutions)
Compliant systems and data (safe solutions)
Scalable systems (responsive solutions)
Manageable systems (responsive solutions)
Reliable systems and data (responsive solutions)
Simple systems (effective solutions)
Modular systems and data (effective solutions)
Maintainable systems (effective solutions)
Mastered systems and data (effective solutions)
Global systems and data (effective solutions)


PART III: System Asset Golden Rules and Measures

Chapter 16: Secure Systems – Golden Rules and Measures

Protect end-user authentication secrets
Control access to important systems and data
Keep web traffic private
Body of evidence
Sanitize inputs from untrusted sources before use
Do not let data become code.
Minimize access to regulated data and protect it when used
Do not place sensitive data in a URL
Use third-party software safely
Catch internet-facing security exposures before they are exploited
Record and report important security related events
Use standard authentication implementations
Use standard encryption implementations
Architect system assets to degrade gracefully when attacked
Deploy system assets only into known safe environments


Chapter 17: Compliant Systems – Golden Rules and Measures

Protect the organization’s intellectual property
Use third-party Intellectual Property (IP) in accordance with its license
Store Source code in a secure and managed repository
Golden rule measures
Ensure end-user interfaces are accessible


Chapter 18: Scalable Systems – Golden Rules and Measures

Deliver acceptable performance under anticipated load
Optimize the cost of capacity
Set appropriate limits on auto-scaling


Chapter 19: Manageable Systems – Golden Rules and Measures

Respond to standard control commands
Publish appropriate operational events and error messages
Publish performance and capacity data
Maintain a complete inventory of all operational resources


Chapter 20: Reliable Systems – Golden Rules and Measures

Record all requests and measure adherence to your SLA
Record all calls made to other assets and measure the dependent assets’ adherence to their SLA
Continue to meet SLA obligations in the event of a single failure
Continue to meet SLA obligations in the event of a site failure
Ensure that functional testing includes at least one test case covering each of the capabilities and features supported
Handle unrecoverable failures and recoverable failures appropriately
Ensure all production changes are repeatable and auditable


Chapter 21: Simple Systems – Golden Rules and Measures

Do not use unmaintained assets or deprecated APIs
Do not couple an asset to an environment
One asset, one team
Follow Placement of Function (PoF)
Package code to facilitate independent releases
Minimize code duplication and complexity


Chapter 22: Modular Systems – Golden Rules and Measures

Expose and consume only well-defined external interfaces
Manage and version control External Interfaces
Do not couple External Interfaces to their implementation
Handle retries appropriately


Chapter 23: Maintainable Systems – Golden Rules and Measures

Make interfaces directly callable without a proprietary library
Trace requests and failures to their source
Appropriately comment source code and interfaces


Chapter 24: Mastered Systems – Golden Rules and Measures

Register the master system asset for every data asset
Keep data quality high
Encapsulate data
Trace data to its source
Do not connect end-user applications directly to data masters
Do not lose data


Chapter 25: Global Systems – Golden Rules and Measures

Handle data in a globalized way
Distinguish third-party translations from company translations
Adapt to the user’s preferred locale


PART IV: Data Asset Golden Rules and Measures

Chapter 26: Compliant Data – Golden Rules and Measures

Classify and manage data according to the data classification
Retain data as required by the business and by legal and regulatory requirements, and destroy thereafter


Chapter 27: Reliable Data – Golden Rules and Measures

Data curation processes are designed and followed
Data schemas are designed and adhered to
Data is accurate
Data is complete
Data is timely
Data quality control processes are defined and followed


Chapter 28: Modular Data – Golden Rules and Measures

Databases and models are defined flexibly to support changing requirements
Meaning is defined separately from presentation and not inferred from presentation
Master data and product data evolve separately


Chapter 29: Mastered Data – Golden Rules and Measures

Each data asset is mastered by one and only one system asset
Master data assets are modeled
Data Enrichments are mastered


Chapter 30: Global Data – Golden Rules and Measures

Number-centric data is stored in a globalized way
Textual data is stored in a globalized way


Chapter 31: Technology Ownership and Operational Readiness


Chapter 32: Asset Ownership


Chapter 33: Architecture Responsibilities


Chapter 34: Software Development Responsibilities


Chapter 35: Testing Responsibilities


Chapter 36: Build-to-Deploy Responsibilities


Chapter 37: Hosting & Operations Responsibilities


Chapter 38: Hosting Security Responsibilities

Security processes
Cloud account management


Chapter 39: End-User Computing Environment Responsibilities


Appendices

Appendix 1: Technology Owner Checklist

Appendix 2: Additional Checklist for the Cloud

Appendix 3: Golden Rules for Systems Quick Reference

Appendix 4: Golden Rules for Data Quick Reference

The method begins with a set of architecture objectives linked to concepts that matter to the business. It then lays out how to build technology platforms from components we call assets and how to manage those assets over time, through the calculation and management of technical debt.

The PBEA method is a pragmatic approach to enterprise technology architecture which is based on the fundamental tenet that technology is never perfect, compromises must be made, and one of the most valuable functions an enterprise architecture group can provide for a company is a method for managing those compromises. We call the cost of these compromises “technical debt”. It is essentially the difference between what we should have spent on technology and what we did spend.
The PBEA method grew from the experience of watching how large technology organizations function (or do not function as the case may be).
You will learn about such essential topics as:

  • Best practices for building, managing, and ultimately evolving an enterprise architecture.
  • Defining principles and golden rules to guide the high-quality creation of the building blocks of products and platforms (assets).
  • Calculating technical debt and assessing the business risk associated with carrying that debt.
  • Identifying and managing the actions required to pay off technical debt and mitigate any associated business risk.

 

If you have witnessed products and platforms ‘collapsing under the burden of technical debt’, then this book is for you. If you have seen technology organizations fail to learn from their mistakes, then this book is also for you. If you have been involved in the development of products where Version 2 required almost a rewrite of Version 1 or worked in technology organizations that spend an excessive portion of their budget on maintenance, then the PBEA method may provide both insight and benefit. Or if you are an enterprise architect and have witnessed one or more Enterprise Architecture functions get eliminated because they were seen as ‘too ivory tower’ and too distant from the customer, then this book will provide you with a concrete, fact-based approach for building an enterprise architecture function that is fully aligned with business objectives and that delivers real measurable benefit to the corporation.

About Ian

Ian Koenig has spent over 35 years in various technology roles most recently as Chief Architect of LexisNexis, a division of Reed Elsevier. Ian was the chief architect for Thomson Financial prior to that and for Reuters before that. His Principle Based Enterprise Architecture (PBEA) method was built from the experience gained as the chief architect of these large corporations, covering multiple industries. He began his career as a software developer and was an early adopter of Microsoft Windows. In 1994, Ian was one of seven individuals presented with the Windows Pioneer Award recognizing him for his contribution to the success of the Microsoft Windows platform.

Bestsellers

Faculty may request complimentary digital desk copies

Please complete all fields.