| |
| |
| Foreword | |
| |
| |
| |
| Foreword | |
| |
| |
| |
| Preface | |
| |
| |
| |
| Software Architecture | |
| |
| |
| Defining Software Architecture | |
| |
| |
| Alternative Thoughts on Software Architecture | |
| |
| |
| Subsystems Are Designed to Manage Dependencies | |
| |
| |
| Subsystems Are Designed According to Human Motivations and Desires | |
| |
| |
| Give in to Great Architectures | |
| |
| |
| Beauty Is in the Eye of the Beholder! | |
| |
| |
| Why Software Architecture Matters | |
| |
| |
| Longevity | |
| |
| |
| Stability | |
| |
| |
| Degree and Nature of Change | |
| |
| |
| Profitability | |
| |
| |
| Social Structure | |
| |
| |
| Boundaries Defined | |
| |
| |
| Sustainable, Unfair Advantage | |
| |
| |
| Creating an Architecture | |
| |
| |
| Patterns and Architecture | |
| |
| |
| Architectural Evolution and Maturation: Features versus Capabilities | |
| |
| |
| Architectural Care and Feeding | |
| |
| |
| Technological Currency | |
| |
| |
| Technological Debt | |
| |
| |
| Known Bugs | |
| |
| |
| License Compliance | |
| |
| |
| Principles First, Second, and Third | |
| |
| |
| Encapsulation | |
| |
| |
| Interfaces | |
| |
| |
| Loose Coupling | |
| |
| |
| Appropriate Granularity | |
| |
| |
| High Cohesion | |
| |
| |
| Parameterization | |
| |
| |
| Deferral | |
| |
| |
| Creating Architectural Understanding | |
| |
| |
| The Team | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Product Development Primer | |
| |
| |
| What Is Product Management? | |
| |
| |
| Why Product Management Matters | |
| |
| |
| Product Development Processes: Creating Release 1.0 | |
| |
| |
| Concept Proposal | |
| |
| |
| Product Proposal/Business Plan | |
| |
| |
| Development Plan | |
| |
| |
| Development | |
| |
| |
| Final Quality Assurance | |
| |
| |
| Prelaunch | |
| |
| |
| Launch | |
| |
| |
| It Isn't Like That | |
| |
| |
| It Is a Waterfall Process and Those Don't Work | |
| |
| |
| It Presents All Stages as If They Were of Equal Importance | |
| |
| |
| It Doesn't Detail Any Time | |
| |
| |
| Where Is the Iteration? | |
| |
| |
| It Doesn't Prescribe a Development Process | |
| |
| |
| It Doesn't Identify the Level of Collaboration Between Groups within Stages | |
| |
| |
| The Business Plan | |
| |
| |
| Product Development Processes: Creating Release n.n.n | |
| |
| |
| Augmenting the Product Development Process | |
| |
| |
| Successive Freezing | |
| |
| |
| Change Management Protocols | |
| |
| |
| Recycle Bin | |
| |
| |
| Crucial Product Management Concepts | |
| |
| |
| The Four Ps of Marketing | |
| |
| |
| Total Available Market, Total Addressable Market, and Market Segmentation | |
| |
| |
| The S-Shaped Curve of Adoption | |
| |
| |
| The Whole Product | |
| |
| |
| Technical versus Market Superiority | |
| |
| |
| Position and Positioning | |
| |
| |
| Brand | |
| |
| |
| The Main Message | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| The Difference between Marketecture and Tarchitecture | |
| |
| |
| Who Is Responsible for What? | |
| |
| |
| Early Forces in Solution Development | |
| |
| |
| Creating Results in the Short Run while Working in the Long Run | |
| |
| |
| Projecting the Future | |
| |
| |
| Harnessing Feedback | |
| |
| |
| Generating Clarity | |
| |
| |
| Working in Unison | |
| |
| |
| Reaching Agreements | |
| |
| |
| Making Data Available | |
| |
| |
| Context Diagrams and Target Products | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Business and License Model Symbiosis | |
| |
| |
| Common Software Business Models | |
| |
| |
| Time-Based Access or Usage | |
| |
| |
| Transaction | |
| |
| |
| Metering | |
| |
| |
| Hardware | |
| |
| |
| Services | |
| |
| |
| Revenue Obtained/Costs Saved | |
| |
| |
| Rights Associated with Business Models | |
| |
| |
| Tarchitectural Support for the Business Model | |
| |
| |
| General Issues | |
| |
| |
| Time-Based Access or Usage | |
| |
| |
| Transaction | |
| |
| |
| Metering | |
| |
| |
| Hardware | |
| |
| |
| Enforcing Licensing Models | |
| |
| |
| The Honor System | |
| |
| |
| Home-Grown License Managers | |
| |
| |
| Third-Party or Professional License Managers | |
| |
| |
| The Client | |
| |
| |
| Market Maturity Influences on the Business Model | |
| |
| |
| Choosing a Business Model | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Technology In-Licensing | |
| |
| |
| Licensing Risks/Rewards | |
| |
| |
| Contracts--Where the Action Is | |
| |
| |
| Contract Basics | |
| |
| |
| License Terms | |
| |
| |
| When Business Models Collide, Negotiations Ensue | |
| |
| |
| Honoring License Agreements | |
| |
| |
| Managing In-Licensed Technology | |
| |
| |
| Open-Source Licensing | |
| |
| |
| License Fees | |
| |
| |
| Licensing Economics | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Portability | |
| |
| |
| The Perceived Advantages of Portability | |
| |
| |
| The Business Case for Portability | |
| |
| |
| Creating Portable Applications | |
| |
| |
| Use an Interpreted Language | |
| |
| |
| Use Standards-Based Persistent Storage | |
| |
| |
| Make Business Logic Portable | |
| |
| |
| Closer to the User Means Less Portability | |
| |
| |
| Use XML for Standardized, Interoperable Communications between Subsystems | |
| |
| |
| Avoid Hiding The Power of a Specific Platform in the Name of Portability | |
| |
| |
| The Matrix of Pain | |
| |
| |
| |
| Remove Configurations | |
| |
| |
| |
| Rank-Order Configurations | |
| |
| |
| |
| Make the Final Cut | |
| |
| |
| Beware the Promises You Make | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Deployment Architecture | |
| |
| |
| Deployment Choices | |
| |
| |
| Customer Site | |
| |
| |
| Application Service Provider | |
| |
| |
| Managed Service Provider | |
| |
| |
| Transactional (Web Service) | |
| |
| |
| Customer Influences on Deployment Architectures | |
| |
| |
| Control and Integration | |
| |
| |
| Data Security/Privacy and Peak Loads | |
| |
| |
| Costs and Vendor Confidence | |
| |
| |
| Customer Skills and Experiences and Geographic Distribution | |
| |
| |
| Corporate Influences on Deployment Architecture | |
| |
| |
| Sales Cycle | |
| |
| |
| Infrastructure Investment | |
| |
| |
| Cash Flow | |
| |
| |
| Flexibility | |
| |
| |
| Geographic Distribution | |
| |
| |
| Service, Not Price | |
| |
| |
| Choosing a Software Deployment Architecture | |
| |
| |
| Deployment Architectures and the Distribution of Work | |
| |
| |
| The Information Appliance | |
| |
| |
| Deployment Choice Influences on Software Architecture | |
| |
| |
| Flexible, Parameterized, or No Integration Options | |
| |
| |
| Upgrade Policies | |
| |
| |
| Data Protection and Access | |
| |
| |
| Migration Options | |
| |
| |
| The Future of Consumer Software | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Integration and Extension | |
| |
| |
| Customer Control--The Driving Force | |
| |
| |
| Motivations for Integration/Extension | |
| |
| |
| Layered Business Architectures: Logical Structures | |
| |
| |
| The User Interface Layer | |
| |
| |
| The Services Layer | |
| |
| |
| The Domain Model Layer | |
| |
| |
| The Persistent Data Layer | |
| |
| |
| Variations on a Theme | |
| |
| |
| Creating Layered Business Architectures | |
| |
| |
| Integration and Extension at the Business Logic Layers | |
| |
| |
| Technologies and Locus of Control | |
| |
| |
| Integration through APIs | |
| |
| |
| Extension through Registration | |
| |
| |
| Integration and Extension of Persistent Data | |
| |
| |
| Views | |
| |
| |
| User Fields | |
| |
| |
| Hook Tables | |
| |
| |
| Spreadsheet Pivot Tables | |
| |
| |
| Extract, Transform, and Load Scripts | |
| |
| |
| Tell Them What's Going On | |
| |
| |
| Business Ramifications | |
| |
| |
| Professional Services | |
| |
| |
| Training Programs | |
| |
| |
| Certification | |
| |
| |
| User Community | |
| |
| |
| License Agreements | |
| |
| |
| Managing APIs Over Multiple Releases | |
| |
| |
| Techniques | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Brand and Brand Elements | |
| |
| |
| Brand Elements | |
| |
| |
| Names | |
| |
| |
| Graphics, Slogans, and Other Brand Elements | |
| |
| |
| When to Use the Trademark Symbol | |
| |
| |
| Managing In-License Brands | |
| |
| |
| Brand Element Customizations | |
| |
| |
| Changing Brand Elements | |
| |
| |
| Product Areas to Change | |
| |
| |
| QA and Change | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Usability | |
| |
| |
| Usability Is about Money | |
| |
| |
| Mental Models, Metaphors, and Usability | |
| |
| |
| Tarchitectural Influences on User Interface Design | |
| |
| |
| Areas of Influence | |
| |
| |
| The Need for Speed | |
| |
| |
| Let's Be Clear on What We're Talking About | |
| |
| |
| What a Marketect Really Wants with Respect to Performance | |
| |
| |
| Responding to the User | |
| |
| |
| Performance And Tarchitectural Impact | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Installation | |
| |
| |
| The Out of Box Experience | |
| |
| |
| Ouch! That Might Hurt | |
| |
| |
| Customer Fears | |
| |
| |
| Installation and Architecture | |
| |
| |
| Forces and Choices | |
| |
| |
| How to Install | |
| |
| |
| Installation Data Collection and Precondition Verification | |
| |
| |
| Installation | |
| |
| |
| Postinstallation Confirmation | |
| |
| |
| Finishing Touches | |
| |
| |
| They Don't Read the Manual | |
| |
| |
| Test the Install and Uninstall | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Upgrade | |
| |
| |
| Like Installation, Only Worse | |
| |
| |
| Upgrade Fears | |
| |
| |
| Making Upgrades Less Painful | |
| |
| |
| Choices for Painless Upgrades | |
| |
| |
| Market Maturity and Upgrades | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Configuration | |
| |
| |
| Configurability--An Element of Usability | |
| |
| |
| The System Context | |
| |
| |
| Contextual Information | |
| |
| |
| Initialization versus Execution | |
| |
| |
| Setting the Value | |
| |
| |
| Setting the Right Value | |
| |
| |
| Configuration Parameter Heuristics | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Logs | |
| |
| |
| I Want to Know What's Happening | |
| |
| |
| Not Just the Facts | |
| |
| |
| Log Format and Management | |
| |
| |
| Log Format | |
| |
| |
| Log Management | |
| |
| |
| Logging Standards and Libraries | |
| |
| |
| Postprocessing Log Data | |
| |
| |
| Logging Services | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Release Management | |
| |
| |
| Yes, You Really Need This | |
| |
| |
| Establishing a Baseline | |
| |
| |
| Release Management | |
| |
| |
| What You're Releasing | |
| |
| |
| Who You're Targeting | |
| |
| |
| Why They Want It | |
| |
| |
| Release Identification | |
| |
| |
| Full or Complete Releases | |
| |
| |
| Partial Releases | |
| |
| |
| Patch Releases | |
| |
| |
| Variations | |
| |
| |
| SKUs and Serial Numbers | |
| |
| |
| SKU Management | |
| |
| |
| Serial Numbers, Registration, and Activation | |
| |
| |
| Release Management Influences on Tarchitecture | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Security | |
| |
| |
| Viruses, Hackers, and Pirates | |
| |
| |
| Managing Risk | |
| |
| |
| See No Evil, Speak No Evil | |
| |
| |
| Digital Identity Management | |
| |
| |
| Authorization--Defining Who Can Do What | |
| |
| |
| Authentication--Proof of Identity | |
| |
| |
| Transaction Security | |
| |
| |
| Auditability--Proof of Activity | |
| |
| |
| Integrity--Preventing Tampering and Alteration of Data | |
| |
| |
| Confidentiality--Keeping Data Away from Those Not Entitled to It | |
| |
| |
| Accountability--Holding People Responsible for Their Actions | |
| |
| |
| Software Security | |
| |
| |
| Software Security Techniques | |
| |
| |
| Software Security Costs/Benefits | |
| |
| |
| Information Security | |
| |
| |
| Secret Algorithms or Secret Keys? | |
| |
| |
| Back Doors | |
| |
| |
| Security and Marketecture | |
| |
| |
| Areas of Interaction | |
| |
| |
| Chapter Summary | |
| |
| |
| Check This | |
| |
| |
| Try This | |
| |
| |
| |
| Release Checklist | |
| |
| |
| |
| A Pattern Language for Strategic Product Management | |
| |
| |
| Applying The Patterns | |
| |
| |
| Capturing the Result | |
| |
| |
| Market Map | |
| |
| |
| Market Events/Market Rhythms | |
| |
| |
| Feature/Benefit Map | |
| |
| |
| The Tarchitecture Roadmap | |
| |
| |
| References | |
| |
| |
| Bibliography | |
| |
| |
| About the Author | |
| |
| |
| Index | |