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:
- 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.
- 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:
- 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.
- 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
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.
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.
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.