Browse All Articles > Online Architecture - Continuous Controlled Change
While internet technology evolves consistently more rapid with each iteration it’s challenging for small web project to keep up. For the larger organization it’s almost impossible to cope with the continuous change. You need to keep track of runtime aspects like user and information security requirements, performance, consistency while not overloading your development and test teams with overly complex processes that will essentially prevent any change from happening.
In the balance between agility and stability it's crucial for web front end engineers to recognize that the playing field is evolving while methodologies mature to facilitate IT and business requirements like these. Component based development and design is one methodology to cope between these force fields.
Online landscapes tend to be spawned from a project based thinking leaving corporations with plenty micro sites, sub sites, (not so) temporary externally developed and hosted sites probably based on as many technological platforms and tools.
It’s quite easy to recognize that the presentation layer, web layer, view layer, customer experience layer or however an organization labels it, is shifting to browser technologies which nowadays mainly consists of HTML, JavaScript and CSS driven from WCM and portal tooling, some extensive customizations and fed by standardized services or a ‘My Company API’.
The typical front end engineers that work in this layer, or this field of expertise tend to like the project based approach, getting things done, be agile, clear scopes, a new challenge every couple of months. The downside of a project approach is often a seemingly consistent experience to the end user, but based on a hardly manageable project from an IT perspective.
From a technology point of view, focusing mainly at CSS, JavaScript and HTML, there is however no reason that standardization cannot take place. Approaches like progressive enhancement, responsive design in a broader sense can go hand in hand perfectly with architectural principles like multichannel consistency, reuse, ownership. It does however require a UX and development realization that takes a component based design and development approach.
Key to the component design are lifecycle management, responsibilities design and proper configuration and release management practices. Result is a provable increase in stability of your overall software and an increase in non functional requirement compliancy like security. A component based design allows you to isolate functionality and test them more thoroughly.
From an UX point of view the standardization process starts with the realization (or discussion, depending on the company you work for) whether the focus is on optimizing a single key application to perfection, or a solid above par base that is implement for all applications, and is designed to scale. Typically this is a 20/80 rule, but for all post-design stages there is a huge impact on what UX approach is taken.
Assuming that a company is willing and able to standardize on a set of some dozen components, the component based thinking throughout the web implementation stages is there. After components are defined for typical UI patterns, the way of thinking can be extrapolated to applications, or views within applications, and aggregated components like application which are aggregations of UI components, and sites are aggregations of applications, content, and possibly even other sites. Again, from a technological point of view, it literally should be less than a few lines of JavaScript to either load a UI Component, or embed a complete application, if the designs of the technical interfaces are proper.
Key benefits of a component based design are:
From an online architecture point of view there are some key topics that need consideration when shifting to the component based approach:
In the balance between agility and stability it's crucial for web front end engineers to recognize that the playing field is evolving while methodologies mature to facilitate IT and business requirements like these. Component based development and design is one methodology to cope between these force fields.
Online landscapes tend to be spawned from a project based thinking leaving corporations with plenty micro sites, sub sites, (not so) temporary externally developed and hosted sites probably based on as many technological platforms and tools.
It’s quite easy to recognize that the presentation layer, web layer, view layer, customer experience layer or however an organization labels it, is shifting to browser technologies which nowadays mainly consists of HTML, JavaScript and CSS driven from WCM and portal tooling, some extensive customizations and fed by standardized services or a ‘My Company API’.
The typical front end engineers that work in this layer, or this field of expertise tend to like the project based approach, getting things done, be agile, clear scopes, a new challenge every couple of months. The downside of a project approach is often a seemingly consistent experience to the end user, but based on a hardly manageable project from an IT perspective.
From a technology point of view, focusing mainly at CSS, JavaScript and HTML, there is however no reason that standardization cannot take place. Approaches like progressive enhancement, responsive design in a broader sense can go hand in hand perfectly with architectural principles like multichannel consistency, reuse, ownership. It does however require a UX and development realization that takes a component based design and development approach.
Key to the component design are lifecycle management, responsibilities design and proper configuration and release management practices. Result is a provable increase in stability of your overall software and an increase in non functional requirement compliancy like security. A component based design allows you to isolate functionality and test them more thoroughly.
From an UX point of view the standardization process starts with the realization (or discussion, depending on the company you work for) whether the focus is on optimizing a single key application to perfection, or a solid above par base that is implement for all applications, and is designed to scale. Typically this is a 20/80 rule, but for all post-design stages there is a huge impact on what UX approach is taken.
Assuming that a company is willing and able to standardize on a set of some dozen components, the component based thinking throughout the web implementation stages is there. After components are defined for typical UI patterns, the way of thinking can be extrapolated to applications, or views within applications, and aggregated components like application which are aggregations of UI components, and sites are aggregations of applications, content, and possibly even other sites. Again, from a technological point of view, it literally should be less than a few lines of JavaScript to either load a UI Component, or embed a complete application, if the designs of the technical interfaces are proper.
Key benefits of a component based design are:
an increase in stability of software, as typically a project iteration (be it waterfall or agile) touches a limited number of components.
increase in test focus on changed components
isolation of responsibilities, which increases overall robustness
re-use of components, depending on granularity and interface design
From an online architecture point of view there are some key topics that need consideration when shifting to the component based approach:
A standardized approach on UX library components requires a management style that isolates the library from projects. It needs a separate governance, its own lifecycles and its own stakeholder management. A centralized governance however does not necessarily mean a centralized development. This depends on a companies IT department organizational layout. Changes to the components inside the library can be executed on a need basis in project context. Governance needs to be centralized. Creation and maintenance of a stakeholder list should be embedded in the organization.
Considering the component hierarchy there should be little difference in integrating a UI component, an application, a single view, multiple views. The starting point is a standardized loading, initialization, unloading and communication design. Even hard to integrate applications can be wrapped to comply with the standardized integration interface.
In front-end the loading of modules is typically supported by an Asynchronous Module Definition framework and need to be topped off by a module definition scheme that fits the organization.
In front-end the loading of modules is typically supported by an Asynchronous Module Definition framework and need to be topped off by a module definition scheme that fits the organization.
Even though from an UX point of view there is a complete component library make sure to decouple the component implementation from the desired functionality.
For example a start of contract date input field in a mobile channel might be a native control, but on the desktop view on a customer channel might be a date picker or calendar, and in the branches and offices implementation might be a three field date input that is more easy to use with a keyboard. This decoupling is slightly different than a typical progressive enhancement / graceful degradation discussion as the selection of UX components is driven by user tests rather than technical capabilities within a channel, and should be configurable or changed across a channel with relatively little work.
For example a start of contract date input field in a mobile channel might be a native control, but on the desktop view on a customer channel might be a date picker or calendar, and in the branches and offices implementation might be a three field date input that is more easy to use with a keyboard. This decoupling is slightly different than a typical progressive enhancement / graceful degradation discussion as the selection of UX components is driven by user tests rather than technical capabilities within a channel, and should be configurable or changed across a channel with relatively little work.
Lifecycle management of components has direct impact on local development, build and releasing of components, integration and testing. While web front end engineers like to have a single workspace where they can browse and touch each and every file and script that ends up in production, the component based thinking will disrupt this way of working. Developers are now confronted with versioning, requirements to finish up components first which are required by others. They need to “release” components, while they feel perfection hasn’t been reached yet. Stable software is not necessarily about perfect software.
Do not pitfall to automate the creation of workspaces, but encourage development to find their way in this new approach. Overall understanding of architectural and design practices, benefits in terms of testing, release management and maintenance are there and aren’t that complex to get a grasp on if you pass the initial hesitation.
Do not pitfall to automate the creation of workspaces, but encourage development to find their way in this new approach. Overall understanding of architectural and design practices, benefits in terms of testing, release management and maintenance are there and aren’t that complex to get a grasp on if you pass the initial hesitation.
The communication on the scope of components and their responsibilities should increase reuse across projects. For projects with tight deadlines (typical all of them) it is often easier to rewrite components than have developers read up on the component library. A poorly documented, poorly separated set of components will drop overall development support, returning back to the days of writing the same code dozens of times, each with their unique set of bugs. The maintenance of the component library will require intensive collaboration between architects, lead designers and developers. The approach should be pragmatic, reasonable, but future proof. Prevent shortcuts that can’t be changed back. Prevent overdesigning for the sake of designing and componentization.
Automate your development street to allow for flexibility in development as well as optimization in production. The creation of a large set of modules can lead to a increased fragmentation and therefore an increased number of files. Processes that aggregate and optimize components typically follow write-once-run-always principles. Simultaneously static test automation should prevent the usage of code that is covered otherwise by standardized components. In web front-end this includes communication libraries, location, session and cookie handling that require more security, better performance and shouldn’t be replicated by projects. Any code style requirement or component usage requirement that isn’t supported by automated processes is bound to slip under the radar.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)