This white paper presents a software-engineering approach for designing, implementing, testing, deploying, and continuously improving a Hyvä child theme for Magento 2 / Adobe Commerce.

The paper integrates principles from two important software-engineering references:

  1. John Ferguson Smart and Jan Molak, BDD in Action, Second Edition — particularly behavior-driven requirements, collaboration, concrete examples, executable specifications, acceptance criteria, automated testing, and living documentation.
  2. Armando Fox and David Patterson, Engineering Software as a Service: An Agile Approach Using Cloud Computing, Second Edition — particularly Agile development, requirements, testing, maintenance, refactoring, design patterns, Dev/Ops, SaaS thinking, and software delivered as an evolving service.

Fox and Patterson's book explicitly includes chapters on BDD and user stories, testing/TDD, maintenance and refactoring, Agile teams, design patterns, and Dev/Ops.

Hyvä provides a modern Magento frontend based on Tailwind CSS and Alpine.js and provides a child-theme mechanism for project-specific customization.

Updated Research White Paper-Research White Paper -A Software Engineering Use Case for a Hyvä Child Theme in Magento 2

Integrating BDD, Agile Software Engineering, SaaS Engineering, DevOps and the Strategic Roles of IAS-Research.com, KeenComputer.com and KeenDirect.com

Research Edition — 2026

Abstract

This white paper presents a software-engineering approach for designing, implementing, testing, deploying, and continuously improving a Hyvä child theme for Magento 2 / Adobe Commerce.

The paper integrates principles from two important software-engineering references:

  1. John Ferguson Smart and Jan Molak, BDD in Action, Second Edition — particularly behavior-driven requirements, collaboration, concrete examples, executable specifications, acceptance criteria, automated testing, and living documentation.
  2. Armando Fox and David Patterson, Engineering Software as a Service: An Agile Approach Using Cloud Computing, Second Edition — particularly Agile development, requirements, testing, maintenance, refactoring, design patterns, Dev/Ops, SaaS thinking, and software delivered as an evolving service.

Fox and Patterson's book explicitly includes chapters on BDD and user stories, testing/TDD, maintenance and refactoring, Agile teams, design patterns, and Dev/Ops.

Hyvä provides a modern Magento frontend based on Tailwind CSS and Alpine.js and provides a child-theme mechanism for project-specific customization.

The paper extends this technical architecture into an organizational engineering model involving:

IAS-Research.com → Research, Requirements, Architecture and Innovation

KeenComputer.com → Software Engineering, DevOps, Security, Deployment and Operations

KeenDirect.com → Magento Commerce, Productization, Supply Chain and Commercialization

The resulting lifecycle is:

Research → Requirements → BDD → Architecture → Development → Testing → DevSecOps → Deployment → Operations → Commerce → Customer Feedback → Continuous Improvement

The Hyvä child theme therefore becomes more than a frontend customization. It becomes a practical case study for disciplined software engineering.

1. Introduction

1.1 Background

Magento 2 and Adobe Commerce provide a sophisticated platform for:

  • Catalog management
  • Product configuration
  • Customer accounts
  • Shopping carts
  • Checkout
  • Payments
  • Shipping
  • Inventory
  • Promotions
  • Search
  • APIs
  • Third-party integrations
  • Content management
  • Business-to-business commerce

However, long-lived Magento projects can accumulate frontend technical debt.

Typical problems include:

  • Excessive JavaScript.
  • Legacy frontend dependencies.
  • Large CSS files.
  • Complex theme overrides.
  • Third-party extension conflicts.
  • Direct modification of vendor files.
  • Poor documentation.
  • Weak automated testing.
  • Difficult upgrades.
  • Performance regressions.
  • Inconsistent responsive behavior.
  • Accessibility defects.

These are fundamentally software-engineering problems, rather than merely web-design problems.

A sustainable Magento storefront therefore requires engineering discipline throughout its lifecycle.

2. Research Question

The central research question is:

How can a Magento organization engineer a customized storefront that remains maintainable, testable, upgradeable, secure, performant, and commercially useful over its operational lifetime?

The proposed answer is a combination of:

  • Hyvä child-theme architecture.
  • Behavior-driven development.
  • Agile iteration.
  • Automated testing.
  • Design patterns.
  • Continuous integration.
  • DevSecOps.
  • Performance engineering.
  • Observability.
  • Continuous improvement.
  • Research-driven architecture.
  • Engineering implementation.
  • Commercial feedback.

3. Software Engineering Foundations

3.1 BDD in Action

BDD in Action, Second Edition describes Behavior-Driven Development as a lifecycle-oriented approach in which collaboration and concrete examples help teams establish a shared understanding of what software should do. Manning describes the book as covering collaboration, concrete requirements, automated tests, and reporting across the software lifecycle.

For the Hyvä project, this means that a requirement should not simply be written as:

"Create a better product page."

Instead, the requirement should become an observable behavior.

For example:

Feature

Product purchase

Scenario

Customer adds an available product to the cart

Given

The customer is viewing an available product.

When

The customer selects the required options and clicks Add to Cart.

Then

The product is added to the shopping cart.

And

The cart quantity and subtotal are updated.

And

The customer receives an appropriate confirmation.

This creates a direct connection:

Business Requirement → Behavior → Acceptance Criteria → Automated Test → Implementation

4. Armando Fox and David Patterson's Software Engineering Model

4.1 Engineering Software as a Service

Fox and Patterson's Engineering Software as a Service presents software engineering through an Agile and cloud/SaaS-oriented perspective. The second edition includes:

  • SaaS and Agile development.
  • Requirements.
  • BDD and user stories.
  • Testing and TDD.
  • Software maintenance.
  • Refactoring.
  • Agile teams.
  • Design patterns.
  • Dev/Ops.

This makes the book particularly applicable to Magento because a modern ecommerce platform should not be treated as a one-time software installation.

It should be treated as a continuously evolving service.

The storefront must continuously respond to:

  • Customer behavior.
  • Product changes.
  • Browser changes.
  • Payment requirements.
  • Security threats.
  • Performance requirements.
  • Marketing requirements.
  • Search-engine changes.
  • Extension updates.
  • Magento updates.
  • Hyvä updates.
  • Business strategy.

5. Combining BDD in Action with Engineering Software as a Service

The two books can be combined into a practical engineering model.

Engineering concern

BDD in Action

Fox & Patterson

Hyvä/Magento application

Requirements

Concrete examples

User stories

Ecommerce requirements

Collaboration

Shared understanding

Agile teams

Product owner + engineers

Acceptance

Executable criteria

Testing

Browser/customer tests

Development

Behavior-driven

Iterative development

Child-theme components

Testing

Automated acceptance

TDD

Magento + browser tests

Maintenance

Living documentation

Refactoring

Theme upgrades

Architecture

Behavior-focused

SaaS/design patterns

Magento/Hyvä architecture

Operations

Feedback

Dev/Ops

CI/CD and monitoring

Improvement

Continuous feedback

Agile iteration

Storefront optimization

This creates a complete engineering loop:

Business Goal | v User Story | v BDD Scenario | v Acceptance Criteria | v Architecture | v Implementation | v Automated Test | v CI/CD | v Production | v Monitoring | v Customer Feedback | +--------------------+ | v New Requirement

6. Strategic Role of IAS-Research.com

6.1 Research and Architecture Layer

IAS-Research.com should occupy the upstream research and engineering-architecture position.

Its strategic question is:

What should be built, why should it be built, and what architecture provides a technically and commercially viable path?

IAS-Research can contribute:

  • Software-engineering research.
  • Architecture research.
  • Requirements engineering.
  • Feasibility studies.
  • AI/ML research.
  • RAG/LLM research.
  • Systems engineering.
  • DevSecOps research.
  • Performance research.
  • Technology evaluation.
  • Reference architectures.
  • Prototyping.
  • Engineering standards.
  • Technical white papers.

This positioning is consistent with the broader three-organization engineering model in which IAS-Research functions as the research and architecture layer.

6.2 IAS-Research and BDD

IAS-Research can facilitate the transition:

Business Problem

↓

Research Question

↓

Requirements

↓

User Stories

↓

BDD Scenarios

↓

Architecture

↓

Prototype

For example:

"Customers are abandoning product pages because product configuration is difficult on mobile."

IAS-Research can investigate:

  • Existing UX.
  • Customer behavior.
  • Technical constraints.
  • Magento architecture.
  • Hyvä capabilities.
  • Mobile performance.
  • Accessibility.
  • Competing implementations.

The result can become a set of measurable BDD scenarios.

7. Strategic Role of KeenComputer.com

7.1 Software Engineering and Implementation Layer

KeenComputer.com becomes the primary implementation and operational engineering organization.

Its strategic question is:

How do we engineer, secure, deploy, monitor and maintain the proposed architecture?

KeenComputer can provide:

  • Magento engineering.
  • Hyvä implementation.
  • PHP development.
  • Linux infrastructure.
  • Docker.
  • Warden.
  • CI/CD.
  • Git workflows.
  • DevOps.
  • DevSecOps.
  • VPS/cloud deployment.
  • Nginx.
  • Redis.
  • OpenSearch.
  • Varnish.
  • Monitoring.
  • Backup.
  • Cybersecurity.
  • WAF.
  • Automated testing.
  • Performance engineering.

The organization can therefore convert an architectural design into a production system.

8. Strategic Role of KeenDirect.com

8.1 Commerce and Productization Layer

KeenDirect.com provides the commercial environment in which the software engineering can be validated.

Its strategic question is:

How does the engineered technology become a usable, measurable and commercially sustainable ecommerce platform?

KeenDirect can address:

  • Magento commerce.
  • Product catalogs.
  • Computer hardware.
  • Components.
  • B2B commerce.
  • B2C commerce.
  • Supply chain.
  • Inventory.
  • Product sourcing.
  • Customer experience.
  • SEO.
  • Digital commerce.
  • Conversion optimization.
  • Customer feedback.
  • Commercial analytics.

The broader organizational model identifies KeenDirect as the productization and commercialization layer connecting engineering with the market.

9. The Three-Organization Engineering Model

The three organizations can therefore operate as a coordinated engineering ecosystem.

Organization

Strategic responsibility

Typical activities

IAS-Research.com

Research and Architecture

Research, requirements, feasibility, architecture, AI, systems engineering

KeenComputer.com

Software and Systems Engineering

Development, DevOps, security, testing, deployment, infrastructure

KeenDirect.com

Productization and Commerce

Magento, ecommerce, hardware, supply chain, commercialization, customer feedback

The lifecycle becomes:

IAS-RESEARCH.COM Research Requirements Architecture Innovation | v KEENCOMPUTER.COM Engineer Integrate Secure Test Deploy Operate | v KEENDIRECT.COM Productize Commerce Supply Market Measure | v Customer Feedback | +--------------------+ | v IAS-RESEARCH

This creates a closed-loop engineering and learning system.

10. Hyvä Child Theme as the Engineering Use Case

10.1 Architecture

Hyvä documentation describes Hyvä as a modern Magento frontend built using Tailwind CSS and Alpine.js and provides guidance for creating and customizing child themes.

The architecture can be represented as:

Customer | v Browser | v Hyvä Child Theme | +-- Templates +-- Layout XML +-- Tailwind CSS +-- Alpine.js +-- Design System +-- Accessibility | v Hyvä Parent Theme | v Magento / Adobe Commerce | +-- Catalog +-- Customer +-- Cart +-- Checkout +-- Payment +-- Shipping +-- Inventory +-- Extensions

The child theme should own project-specific presentation behavior, while the parent theme provides reusable platform functionality.

11. BDD Requirements for the Hyvä Child Theme

BDD can be applied to every major ecommerce journey.

11.1 Product Page

Feature

View product information

Scenario

Customer views a product on a mobile device

Given

The product exists and is available.

When

The customer opens the product page.

Then

The product name, image, price and availability are displayed.

And

The layout is usable on the customer's viewport.

And

The page meets defined accessibility requirements.

And

The page satisfies the project's performance acceptance criteria.

12. Product Configuration

Feature

Configure a product

Scenario

Customer selects required product options

Given

A product contains required configurable options.

When

The customer selects valid options.

Then

The selected configuration is reflected in the interface.

And

The correct price is displayed.

And

The customer can add the configuration to the cart.

This scenario can become an automated browser test.

13. Shopping Cart

Feature

Manage shopping cart

Scenario

Customer changes product quantity

Given

The cart contains a product.

When

The customer changes the quantity.

Then

The cart is updated.

And

The subtotal is recalculated.

And

The displayed quantity is correct.

And

The operation does not introduce an unacceptable interaction delay.

14. Checkout

Feature

Complete checkout

Scenario

Customer completes an eligible purchase

Given

The customer has a valid cart.

When

The customer provides shipping and payment information.

Then

The order is successfully submitted.

And

The order confirmation is displayed.

And

The appropriate analytics event is generated.

And

Sensitive information is handled according to security requirements.

15. Child Theme Design Principles

15.1 Prefer Extension Over Duplication

Hyvä documentation specifically recommends using referenceBlock when modifying blocks already declared by a parent theme rather than copying the parent's block declaration into the child theme. Copying declarations can mask future parent-theme changes and make upgrades more difficult.

Therefore:

<referenceBlock name="example">

should generally be preferred over unnecessarily reproducing:

<block name="example">

This is a direct application of maintainability and loose coupling.

16. Separation of Concerns

The child theme should distinguish:

Layout

Where components appear.

Templates

What HTML is rendered.

Tailwind

How components are styled.

Alpine.js

How lightweight interactions behave.

Magento services

Business logic.

APIs

System integration.

CI/CD

Build and deployment.

Monitoring

Production behavior.

This separation prevents the frontend template from becoming a container for unrelated business logic.

17. Tailwind CSS Engineering

Tailwind should be treated as part of the project's design system rather than merely a collection of CSS utility classes.

The design system should define:

  • Colors.
  • Typography.
  • Spacing.
  • Breakpoints.
  • Borders.
  • Shadows.
  • Focus states.
  • Component states.
  • Responsive behavior.

The child theme must also correctly account for parent-theme source files when generating the production stylesheet. Hyvä's documentation identifies parent-theme inclusion as an important child-theme build configuration requirement.

18. Alpine.js Engineering

Alpine.js should be used for localized behavior such as:

  • Menus.
  • Accordions.
  • Modals.
  • Tabs.
  • Product selectors.
  • Interactive filters.
  • Small progressive-enhancement components.

The engineering principle should be:

Use the smallest amount of client-side behavior necessary to satisfy the requirement.

This helps maintain a simpler frontend architecture.

19. Testing Architecture

The project should combine:

BDD | +-- Acceptance Tests | +-- Integration Tests | +-- Unit Tests | +-- Browser Tests | +-- Accessibility Tests | +-- Security Tests | +-- Performance Tests | +-- Production Monitoring

BDD establishes what the system should do.

TDD and unit testing help verify how individual components behave.

Integration testing verifies how components work together.

Browser testing verifies the customer's actual interaction.

Performance monitoring verifies how the production system behaves under real conditions.

20. CI/CD Architecture

A production workflow can be:

Developer | v Git Commit | v Static Analysis | v BDD / Acceptance Tests | v Unit Tests | v Integration Tests | v Tailwind Build | v Browser Tests | v Accessibility | v Security Scan | v Performance Regression | v Staging | v Business Acceptance | v Production | v Monitoring

This is consistent with Fox and Patterson's emphasis on Agile development, testing, maintenance and Dev/Ops.

21. Performance Engineering

The project should establish measurable performance requirements.

Important metrics include:

  • LCP.
  • INP.
  • CLS.
  • TTFB.
  • JavaScript size.
  • CSS size.
  • Image weight.
  • Number of network requests.
  • Server response time.
  • Checkout latency.

Current Core Web Vitals guidance identifies LCP, INP and CLS as the principal user-experience metrics, with "good" thresholds of 2.5 seconds for LCP, 200 ms for INP and 0.1 for CLS at the 75th percentile.

Performance must nevertheless be treated as an engineering requirement rather than an automatic benefit of adopting Hyvä.

22. Security Engineering

The child theme should be incorporated into the organization's DevSecOps process.

Security controls should include:

  • Output escaping.
  • Content Security Policy.
  • Dependency scanning.
  • Secure Composer dependencies.
  • Third-party JavaScript review.
  • XSS prevention.
  • Authentication testing.
  • Checkout security testing.
  • Secure deployment.
  • WAF.
  • Monitoring.
  • Backup.
  • Incident response.

KeenComputer can integrate the storefront into a broader Magento security architecture involving WAF, monitoring, backups, vulnerability management and DevSecOps.

23. DevOps and SaaS Thinking

A Magento ecommerce site should not be viewed as:

"A website that was finished and deployed."

Instead:

It is a continuously evolving digital service.

This perspective follows the SaaS-oriented engineering philosophy described by Fox and Patterson.

The service continuously receives:

  • Code updates.
  • Theme updates.
  • Magento updates.
  • Security patches.
  • Product updates.
  • Extension updates.
  • Marketing changes.
  • Customer feedback.
  • Performance data.

Therefore:

Development + Operations + Feedback = Continuous Software Engineering

24. Maintenance and Refactoring

One of the most important applications of Fox and Patterson's approach is treating maintenance as a normal engineering activity rather than a failure of the original implementation.

A Hyvä child theme should periodically be reviewed for:

  • Unused templates.
  • Obsolete overrides.
  • Duplicate components.
  • Unused CSS.
  • Unnecessary JavaScript.
  • Outdated compatibility modules.
  • Deprecated Magento functionality.
  • Parent-theme differences.
  • Security issues.
  • Performance regressions.

The objective is to prevent:

Child Theme → Override Accumulation → Technical Debt → Upgrade Difficulty

from becoming the project's long-term trajectory.

25. Upgrade Management

Every Hyvä upgrade should include an override audit.

The process should be:

New Hyvä Version | v Review Parent Changes | v Compare Child Overrides | v Identify Conflicts | v Run BDD Tests | v Run Browser Tests | v Run Performance Tests | v Deploy to Staging | v Production

The child theme therefore becomes an explicit upgrade boundary.

26. KeenComputer as the Engineering Laboratory

KeenComputer can use Magento/Hyvä projects as practical software-engineering laboratories.

The organization can develop reusable engineering standards for:

  • Magento.
  • Hyvä.
  • Docker.
  • Warden.
  • CI/CD.
  • DevSecOps.
  • VPS hosting.
  • Nginx.
  • Redis.
  • Varnish.
  • OpenSearch.
  • Wazuh.
  • Nagios.
  • Automated testing.
  • Performance engineering.

The resulting knowledge can be reused across SME projects.

27. KeenDirect as a Commerce Proving Ground

KeenDirect can provide a real-world environment in which engineering practices are evaluated against:

  • Product catalogs.
  • Real customers.
  • Product search.
  • Inventory.
  • Payments.
  • Shipping.
  • Customer journeys.
  • Conversion.
  • Performance.
  • Security.
  • Supply-chain requirements.

This makes KeenDirect more than an ecommerce website.

It becomes a commercial validation environment.

28. IAS-Research and Advanced Engineering

The Magento/Hyvä use case can also become a research platform for:

  • AI-assisted software engineering.
  • RAG-based developer knowledge systems.
  • Automated test generation.
  • AI-assisted code review.
  • Performance analysis.
  • Security analysis.
  • DevSecOps automation.
  • Software architecture research.
  • Knowledge graphs.
  • Engineering agents.

For example, a RAG-LLM system could ingest:

  • Magento documentation.
  • Hyvä documentation.
  • Project architecture.
  • Coding standards.
  • BDD specifications.
  • Test cases.
  • Deployment procedures.
  • Incident reports.

Developers could then query the project's engineering knowledge base.

29. Strategic Integration with Other Projects

The same engineering model can be applied to other IAS-Research/KeenComputer/KeenDirect projects.

Examples include:

OBD-AI

Research:

IAS-Research

Vehicle diagnostics, RAG, AI, CAN, knowledge graphs.

Engineering:

KeenComputer

Applications, APIs, infrastructure, Docker, mobile/backend integration.

Commercialization:

KeenDirect

Automotive diagnostic products, equipment, tools and services.

Smart Inverter / DER

IAS-Research:

  • Power electronics.
  • Grid-edge systems.
  • EV/PV.
  • AI.
  • Simulation.
  • Control systems.

KeenComputer:

  • Software.
  • Monitoring.
  • IoT.
  • Cloud.
  • DevOps.
  • Cybersecurity.

KeenDirect:

  • Components.
  • Equipment.
  • Productization.
  • Commercial distribution.

30. Engineering Governance

A project governance model can assign:

Decision

Primary responsibility

Research question

IAS-Research

Technical feasibility

IAS-Research

System architecture

IAS-Research + KeenComputer

Requirements

Joint

BDD specifications

Joint

Magento implementation

KeenComputer

Hyvä implementation

KeenComputer

Security architecture

IAS-Research + KeenComputer

Infrastructure

KeenComputer

Production operations

KeenComputer

Ecommerce product strategy

KeenDirect

Product sourcing

KeenDirect

Customer feedback

KeenDirect

Continuous improvement

All three

This prevents responsibility from becoming fragmented.

31. Business Value

The combined model provides value at several levels.

Technical Value

  • Better architecture.
  • Better maintainability.
  • Better testing.
  • Better documentation.
  • Better upgradeability.

Operational Value

  • Controlled deployment.
  • Monitoring.
  • Security.
  • Repeatability.
  • Reduced operational surprises.

Commercial Value

  • Better ecommerce experience.
  • Measurable customer behavior.
  • Better product presentation.
  • Faster experimentation.
  • Improved connection between technology and revenue.

Strategic Value

The most important benefit is the creation of a repeatable system for moving from:

Problem → Research → Engineering → Product → Market → Feedback

32. Recommended Engineering Operating Model

The complete model can be summarized as:

BUSINESS PROBLEM | v IAS-RESEARCH.COM Research / Requirements Architecture / Innovation | v BDD / USER STORIES | v KEENCOMPUTER.COM Software / DevOps / Security Testing / Deployment | v HYVÄ / MAGENTO | v KEENDIRECT.COM Ecommerce / Productization Supply / Commerce / Market | v CUSTOMER DATA | v CONTINUOUS FEEDBACK | +------------> IAS-RESEARCH

This creates a continuous engineering-learning cycle rather than a one-time project.

33. Implementation Roadmap

Phase 1 — Research

IAS-Research

  • Business problem.
  • Market research.
  • Technical research.
  • Requirements.
  • Feasibility.
  • Architecture.

Phase 2 — BDD Definition

IAS-Research + KeenComputer + KeenDirect

  • User stories.
  • Features.
  • Scenarios.
  • Acceptance criteria.
  • Definition of Done.

Phase 3 — Engineering

KeenComputer

  • Magento.
  • Hyvä.
  • Child theme.
  • Tailwind.
  • Alpine.js.
  • APIs.
  • Extensions.
  • Infrastructure.

Phase 4 — Verification

KeenComputer

  • Unit testing.
  • Integration testing.
  • BDD acceptance testing.
  • Browser testing.
  • Accessibility.
  • Security.
  • Performance.

Phase 5 — Commercial Validation

KeenDirect

  • Product presentation.
  • Customer journey.
  • Conversion.
  • Ecommerce analytics.
  • Product and inventory validation.

Phase 6 — Production

KeenComputer + KeenDirect

  • Deployment.
  • Monitoring.
  • Backup.
  • Security.
  • Commerce operations.

Phase 7 — Continuous Research

IAS-Research

  • Analyze results.
  • Identify improvements.
  • Research emerging technology.
  • Develop new prototypes.
  • Feed results into the next engineering cycle.

34. Strategic Conclusions

The Hyvä child theme should not be treated simply as a Magento styling mechanism.

It can be used as a practical demonstration of modern software engineering.

The combination of:

  • BDD in Action
  • Engineering Software as a Service
  • Hyvä architecture
  • Magento engineering
  • DevOps
  • DevSecOps
  • automated testing
  • performance engineering
  • continuous improvement

creates a much stronger engineering methodology.

The strategic organizational model adds another dimension.

IAS-Research.com

Research → Requirements → Architecture → Innovation

KeenComputer.com

Engineering → Integration → Security → Testing → Deployment → Operations

KeenDirect.com

Productization → Commerce → Supply → Customer Feedback

Together:

Research → BDD → Architecture → Engineering → Testing → DevSecOps → Deployment → Commerce → Feedback → Research

This is a repeatable model for engineering software products rather than merely developing websites.

35. Final Engineering Principle

The central principle of this white paper is:

Build the Magento storefront as an evolving software product, not as a collection of theme customizations.

The Hyvä child theme provides the architectural boundary.

BDD provides the behavioral requirements.

Fox and Patterson's Agile/SaaS engineering approach provides the lifecycle discipline.

KeenComputer provides engineering and operations.

IAS-Research provides research, architecture and innovation.

KeenDirect provides commerce, productization and market feedback.

The result is an integrated engineering system:

Think → Specify → Engineer → Test → Deploy → Operate → Commercialize → Measure → Learn → Improve

References

Primary Software Engineering References

1. Fox, Armando, and David Patterson

Fox, A., & Patterson, D. A. (2020). Engineering Software as a Service: An Agile Approach Using Cloud Computing (2nd ed.). Pogo Press.

The second edition covers Agile development, requirements, BDD/user stories, testing, maintenance/refactoring, Agile teams, design patterns and Dev/Ops.

Engineering Software as a Service — official book site

Armando Fox — Books

2. Smart, John Ferguson, and Jan Molak

Smart, J. F., & Molak, J. (2023). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle (2nd ed.). Manning Publications. ISBN 978-1-61729-753-3.

The second edition presents BDD as a lifecycle approach involving collaboration, communication, concrete requirements, executable specifications and automated tests.

BDD in Action, Second Edition — Manning

3. Smart, John Ferguson

Smart, J. F. (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications. ISBN 978-1-61729-165-4.

The first edition established the BDD-in-practice framework used as a foundation for the expanded second edition.

Magento and Hyvä References

4. Hyvä Themes

Hyvä. Hyvä Documentation — Building Your Theme.

The documentation describes creating child themes, Tailwind CSS configuration, templates, layouts and frontend customization.

Hyvä Documentation

5. Hyvä Themes

Hyvä. Referencing Parent-Theme Blocks.

This documentation recommends using referenceBlock when modifying blocks inherited from a parent theme, helping avoid unnecessary duplication and upgrade complications.

6. Magento / Adobe Commerce Documentation

Adobe. Adobe Commerce Developer Documentation. Adobe Commerce/Magento architecture, modules, themes, layouts, deployment and development practices.

Adobe Commerce Developer Documentation

Web Performance References

7. Google web.dev

Google. Web Vitals.

Provides guidance concerning Core Web Vitals, field measurement, laboratory testing and real-user performance.

Web Vitals — Google web.dev

Strategic Organizational References

8. KeenComputer.com

KeenComputer.com. Engineering Software for Business and Technical Value: An Integrated Research, Engineering and Productization Model Using IAS-Research.com, KeenComputer.com and KeenDirect.com. 2026.

The framework describes IAS-Research as the research/architecture layer, KeenComputer as the engineering/deployment/operations layer, and KeenDirect as the productization, supply-chain and commercialization layer.

9. KeenComputer.com

KeenComputer.com. From Project Delivery to Digital Engineering Excellence. 2026.

The paper describes the lifecycle:

Research → Strategy → Technology → Implementation → Commercialization.

10. KeenComputer.com

KeenComputer.com. AI-Agent-Enabled DevSecOps Operating System for WordPress, Joomla and Magento. 2026.

The work describes IAS-Research as a research/engineering layer and KeenDirect as a production ecommerce proving ground for Magento, Hyvä, Docker, CI/CD, security and performance practices.

11. KeenComputer.com

KeenComputer.com. From Technology Catalogue to Decision Architecture. 2026.

This framework positions IAS-Research around research, strategy, architecture and innovation; KeenComputer around implementation, modernization, security and operations; and KeenDirect around technology supply and procurement.

36. Recommended Reference Architecture

The research presented in this paper can ultimately be summarized by the following architecture:

┌───────────────────────┐ │ CUSTOMER │ │ Needs / Behavior │ │ Feedback / Revenue │ └───────────┬───────────┘ │ v ┌───────────────────────┐ │ KEENDIRECT.COM │ │ Commerce / Product │ │ Supply / Market │ └───────────┬───────────┘ │ v ┌───────────────────────┐ │ KEENCOMPUTER.COM │ │ Software Engineering │ │ Magento / Hyvä │ │ DevOps / DevSecOps │ │ Deployment / Ops │ └───────────┬───────────┘ │ v ┌───────────────────────┐ │ IAS-RESEARCH.COM │ │ Research / BDD │ │ Requirements │ │ Architecture │ │ Innovation │ └───────────┬───────────┘ │ └───────────────┐ │ v Continuous Improvement

The key idea is that software engineering does not end at deployment.

Deployment creates the next source of requirements.

Commerce creates customer evidence.

Customer evidence creates research questions.

Research creates architectural improvements.

Architecture creates new engineering work.

Engineering creates the next software release.

That is the foundation of a sustainable software-engineering organization.