The Astrix Blog

Expert news and insights for scientific & technology professionals.

The Life Science Industry Blog for R&D Professionals

The Astrix Approach: Practical Enterprise Architecture for the Laboratory

Posted on Lab Informatics. March 7, 2018

Industry-leading enterprises invest heavily in laboratory IT initiatives to drive improvements in operational efficiency, regulatory compliance and innovation. For organizations implementing complex laboratory informatics systems such as LIMS, ELNs, and scientific data management systems (SDMS), creating a fully-integrated laboratory environment that fosters digital continuity across the project lifecycle is an important key to driving innovation and remaining competitive.

Integration requirements for laboratory informatics systems often include laboratory devices and instruments, as well as enterprise systems that need access to laboratory data. To accomplish an integrated laboratory environment that provides a high level of business value for your organization, it is important to design a laboratory informatics architecture that is aligned with business goals, along with a roadmap to deployment, before engaging in a proper technology selection process for your organization.

David Dorsett, Astrix Enterprise Architect, recently gave a webinar entitled “Practical Enterprise Architecture for the Laboratory.” In this blog, we will summarize the important points from this webinar, and expand on how your organization can maximize the business value of your laboratory environment by applying a practical Enterprise Architecture for the laboratory.

Enterprise Architecture

According to Gartner, “Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions.”

It’s not just about the technology

An Enterprise Architect works to create an IT roadmap that maximizes business value for an organization, but it is not just about technology. Using the best and most appropriate technologies available to optimize the IT infrastructure is certainly important, but Enterprise Architecture must balance the requirements for people, process and technology.

Think of Enterprise Architecture as a three-legged stool that can only stand if all three legs are solid. You have to consider trade-offs between particular candidate architectures and people processes. Sometimes, the best solution is to let people do more and the technology do less. Trying to do too much with the technology can often lead to an architecture that is too complex and difficult to support.

Simplicity is an important factor

While complexity may be unavoidable in some situations, it’s wise to keep the design as simple as possible when doing Enterprise Architecture. That said, it’s also important to avoid pushing necessary complexity into a different domain by not addressing the problem when designing architecture for a specific area (e.g., the laboratory). A good Architect designs just the right amount of complexity into the system in the proper areas to meet the necessary requirements for optimizing business value.

Integration is a critical aspect at the enterprise level

At the Enterprise level, integrations are critical aspects. A lot of architecture effort and expenditure is done at the Enterprise integration level – bringing together manufacturing systems and late stage systems in product developments, trying to bridge the gap between the research data handoff into product development efforts, etc. Looking at these handoffs, it’s unlikely that a pure technology solution is going to work in most cases – people and process need to be considered as well.

Non-functional aspects of the architecture

While the biggest focus of most architecture plans is satisfying functional requirements, the biggest issues down the road stem from non-functional aspects (e.g., system support after go-live). Typically, non-functional aspects of architecture do not get enough attention. For Enterprise Architecture to be successful, you have to look beyond the implementation.

These non-functional aspects are critical to the success of the system post go-live, and they are thus often the difference between having happy or unhappy business people. Enterprise Architects must do adequate planning to ensure that the system can be supported down the road:

System administration – The Enterprise Architecture should speak to the boundary conditions around which all the components of the system have to abide by in order to have system incidents be diagnosable. When an issue/bug shows up after go-live, technicians must be able to quickly determine what’s wrong, what’s the cause, and how fast it can be addressed.
Updates (even minor ones) – How is data migrated? How is regression going to be addressed? rapid growth, the system must be flexible enough to allow for integration of new systems. What happens when the company has to divest a unit? Is the data extractable from this system in a way that meets the business requirements? What about the archival and retirement of systems? How will data be moved into appropriate places to meet record management requirements? You have to be able to manage the data lifecycle with respect to business events
Performance, reliability and scalability – You can have the best system in the world when it is functioning, but if it is down often during critical times, it will not be a successful system. Additionally, if the system is difficult to deploy to another site and add more users, it will not be a successful system.
Flexibility (for new integrations) – If the business will be undergoing M&As and/or divestitures, flexibility of the system will be an important non-functional characteristic for success. You have to be able to manage the data lifecycle with respect to business events. What happens when the company has to divest a unit? Is the data actually extractable from the system in a way that meets the business requirements? What happens with M&As? Enterprise Architects must build flexibility into the system to handle both planned and unplanned business events.

Practical Architecture

In the real world, lots of IT systems are built without an architecture. Oftentimes, the architecture of a project simply grows organically (emergent) as the systems are built and the project evolves. While not every project needs to design an architecture, Astrix spends a lot time working with organizations to correct some of the issues that have arisen from an emergent architecture.

Characteristics of projects that may benefit from architectural design include:

Large – Large user base, large amount of data, large scope of business processes.
Heavily integrated – Architectural guidance can be of significant benefit to projects involving integration between COTS systems.
Multi-process and/or multi-site – The more work processes the project is designed to handle, and the more sites are involved in the project, the more it can benefit from an Enterprise Architecture approach.
Mission critical – Architectural guidance is important when reliability and availability of the system are high priority to the business.
Long-lived – Long-lived systems need to be flexible so they are adaptable to changing conditions and technologies over the long term.

The reality is that projects that can benefit from EA are typically complex and require a flexible, agile and a rigorous approach to architectural design. For Enterprise Architecture to be practical and deliver real world value, the architecture plan that is delivered to the customer must satisfy a number of criteria:

Makes actual decisions – The architectural documentation needs to make statements to the effect of “We are doing this, and we are not doing that.”
Describes a deliverable real-world system – An architecture that remains on paper (slideware or vaporware) because it is not practical to build does not provide value.
Has specifics that address risks to increase the probability of success – Risk identification and risk analysis should be addressed in the architectural documentation and should be part of the system design.
Provides guidance – The architecture plan should provide some guidance on how to move through anticipated obstacles during the implementation, and on adapting to change after the implementation.
Contains multiple candidate approaches with trade-offs – Architecture documents should detail different approaches and discuss the trade-offs involved in each, along with a discussion of the criteria that were used to determine the chosen approach. Sometimes, unanticipated obstacles appear in the midst of a project that changes the nature of the trade-offs involved and can lead you down a different architectural path. You will be better prepared for this eventuality if different candidate architectures are explored in the beginning.

Conversely, there are a number of characteristics that are inherent in an impractical architecture plan that will likely fail to deliver significant business value:

Fully prescriptive, especially towards the more distant future – These types of architectures are more of a project plan or checklist with no discussions of trade-offs between different approaches.
Completely non-prescriptive (slideware) – The deliverable is a powerpoint document with not much content – no decisions made, not trade-offs discussed, no risks identified.
Not implementable – The architecture document describes something that cannot be implemented.
Nothing about risk – The risks that threaten project success are not explored in any way.
Nothing controversial – The architecture document is so high level that no one could disagree with it.

Laboratory Architecture

Laboratories are dynamic places where change, both planned and unplanned, happens regularly. For example, a user interface can be designed to rigidly move the user through a workflow that may cover 80% of what the scientist is doing today in their lab. But what if a new instrument is purchased that changes the workflow significantly? Will the architectural design accommodate this shift easily?

Rapid change is especially evident in R&D laboratories, where the nature of exploratory science can lead to rapidly changing work processes. When doing EA for the lab, the architect must put the scientist first. This means that the architecture and design of the user interface, data management, and the way the business processes are managed must embrace the unexpected by having sufficient flexibility to be able to meet the changing dynamics of laboratories.

On the flip side, Astrix architects have seen system designs that are so flexible, with so many aspects that can be changed, that they are difficult to administer (e.g., upgrade). When systems that are designed to be highly flexible take a scattered approach to architecture, you end up not addressing the non-functional requirement of being able to update and upgrade the system. A good architectural plan contains a well thought out and balanced approach to designing the right amount of flexibility into the system.

The Astrix Approach™ to Enterprise Architecture

The Astrix Approach™ to Enterprise Architecture for the lab follows a best practice Value Engineerin g methodology to create a strategy that aligns business requirements, technology and people in your organization.

To create the architectural plan, our experienced professionals follow these steps in the order given:

Immersion in the future business processes – The architect first reviews the results of a comprehensive Business Process Analysis that defines the optimized future-state workflows and requirements for your organization.
Lay out the constraints – By working with the customer’s management team, our architects determine system constraints (e.g., financial, time, technical, etc.).
Identify the uncertainties and probabilities associated with them – Parts of future business process or constraints that have a level of uncertainty are identified.
List the technology goals – Working with customer stakeholders, our architects note relevant technology goals (e.g., system should be cloud-based, needs to be accessible to partners via web portal, mobile accessible, etc.).
Characterize the current-state – the current-state analysis performed by our Business Analysts is examined to better understand the starting point (both in terms of work processes and technologies used) for the architectural plan.

The detailed architectural plan that is delivered to the customer by Astrix Enterprise Architects at the end of the process will contain all the features of a practical Enterprise Architecture described above – candidate architectures, recommended architecture, evaluation criteria, risk identification and analysis, guidance on how to navigate anticipated obstacles during and post implementation.

Conclusion

Laboratory informatics projects can be extremely costly in terms of time, money and resources. Projects that are large, heavily integrated, multi-process or multi-site, mission critical or long-lived can benefit from Enterprise Architecture applied as part of a comprehensive approach to ensure the success of your laboratory informatics project.

Astrix professionals have the skills and expertise necessary to architect, implement, integrate and support best in class solutions for your organization’s laboratory environment. If you have any questions about Astrix Technology Group service offerings, or if you would like to explore how to optimize your laboratory informatics strategy, contact us today to set up a no-obligations consultation.

About the Author

Dave Dorsett has more than three decades of experience in R&D informatics throughout the global pharmaceutical, chemical, and consumer goods industries. He has an extensive track record architecting, designing, and delivering commercial and in-house informatics solutions across the R&D spectrum, from early research through late-stage development.