Tag: architecture

EA

Optimizing Enterprise Architecture Initiatives: Partnering Model and Essential Stages

Jared Meredith

In the ever-evolving landscape of enterprise architecture, the journey from discovery to implementation is a complex yet rewarding process. Through this process there are critical phases of this journey, with every portion focused in how you partner with your teams. Join me as we navigate through these essential stages, offering insights and best practices to ensure your enterprise architecture initiatives thrive.

The Discovery Phase is crucial for understanding the key people involved, their goals, and the challenges ahead. This phase involves identifying strategic priorities to support business outcomes and envisioning the ideal future state without limitations. It also includes planning timelines, understanding deliverables, and ensuring that teams are well-coordinated. By addressing these aspects, we can proactively evaluate and review our progress, tailoring our vision to meet reality while supporting ongoing needs.

During the Initial Architecture Reviews, the focus shifts to designing and presenting the architecture. This involves documenting the current state, defining technical requirements for the future state, and accounting for any third-party dependencies. The design must comply with architectural standards and be pre-aligned with build teams. Once the design is ready, it is presented to the architecture review board and stored for long-term use. The iterative review process includes listening to feedback, learning from ongoing changes, and improving processes to accelerate compliant development. This ensures that documentation and education are effectively conveyed to support teams and stakeholders.

Last but not least, the Iterative Architecture Reviews emphasizes continuous improvement and adaptation. It involves regularly assessing how well the processes are working and identifying areas for enhancement. By staying informed about ongoing movements and changes, teams can plan ahead and allocate time for understanding new upcoming work. This phase also focuses on conveying documentation and education effectively, ensuring that everyone involved is well-informed and capable of contributing to the enterprise architecture’s success.

Let’s now take a deeper dive in how the partnering model comes together with each of these phases:

Enterprise Architecture Partnering Model

As seen above the partnering model doesn’t end once an architecture is drawn; if anything it only continues to iterate over time. To show this better, here’s a full breakdown of each phase of the partnering model with key questions that should be understood at each part:

Understanding (Part of Discovery)​

  • Who are the key people to work with? ​
  • What are their goals? their team goals? ​
  • What are the challenges ahead? ​
  • What do we not know yet that will help us understand? ​
  • How can we help support the ongoing needs? ​

Visioning (Part of Discovery)​

  • What are the strategic priorities to support business outcomes? ​
  • What is the north star? What is the ideal future state with no limitations? ​
  • How are we aiming towards the dream state over 1 year? 3 years? 5 years? ​
  • What can we do to be proactive in evaluation and review? ​
  • How can we tailor the dream to meet reality? ​

Planning (Part of Discovery)​

  • Do we have a timeline and understanding of the deliverables? ​
  • When and how are the teams meeting? ​
  • How can we get plugged into the ongoing conversations? ​
  • Have we planned enough time to evaluate and design the architecture? ​
  • Who is involved to help manage the gates through the project lifecycle? ​

Designing (Part of Initial Architecture Reviews)​

  • Do we have an understood and documented current state? ​
  • Do we have technical requirements to support the future state? ​
  • Are there 3rd party external dependencies to account for? ​
  • Does the design accommodate to architectural design standards?​
  • Have the designs be pre-aligned with build teams prior to architecture review? ​

Presenting (Part of Initial Architecture Reviews)​

  • Does the diagram comply with architectural design standards? ​
  • Has the diagram been presented to architecture review board? ​
  • Has the diagram been stored for long-term use with support teams? ​
  • Has the status of the review been communicated to the project/program teams? ​
  • Have we validated the design with any 3rd party external support? ​

Listening (Part of Iterative Architecture Reviews and Discovery)​

  • How are we doing? What can be shared about what could be better? ​
  • Where can we learn of ongoing movement or changes? ​
  • How can we improve any processes or standards to accelerate compliant development? ​
  • How can we plan ahead to make time for building understanding of new upcoming work? ​
  • How are we conveying documentation and education to others that they may learn more about EA? ​

As you work to develop your EA partnerships I know that you’ll see these themes as you go along. I hope this has been helpful, happy architecting!

Blog, CMS, Web, Wordpress

Enterprise Website Consolidation: What I Did, and Why You Should

Jared Meredith

When you are a responsible party concerning your companies’ websites, many challenges come up along the way. And one of the toughest challenges I have faced in my career supporting enterprise architecture was working with business partners to make an enterprise decision over an easy one.

The Problem: Over the course of weeks, my discovery revealed 25 separate websites across 5 different content management systems (CMS), hosted in 10 different servers and locations. Websites in the same CMS platforms were on different versions of the same CMS as well as infrastructure patching schedules. There was no form of source control nor any consistent configuration around the administration services. These complexities not only led to continual issues that had to be managed daily but in turn tied up development resources from focusing on other work. The conclusion was clear that over time the management of the web CMS systems and IT resources would continue to bloat cost and time to delivery on new projects.

What seems like the right idea: As these problems continue to come up, I recall this being presented in ideas and exploration, “Let’s just put more people on all of these to get them updated. The issue with the easy decision, however, is that the one-time fixes only prolong the root problems. You may have very sharp employees that are more than capable of knocking out these odds and ends jobs, but as any other updates begin to repeat themselves, the cycle repeats itself once more.

The Enterprise Solution: After all research had been done, the answer was clear: consolidating websites down into the same CMS would reduce the ongoing people support issues while improving the time to delivery on projects. The CMS itself needed to be a platform that allowed for scalability and ease of configuration. Finally, automation was going to be key in how it would assist in accomplishing operations and tasks that reduced unneeded internal labor.

The Results? 80% overall savings: After a 2 1/2-year transformation, 25 external websites were consolidated into WordPress via WP Engine. WP Engine was our manage services platform of choice, providing enterprise capabilities for all sites with a single pane of glass CMS management experience. Comparing against the 3-year cost-to-date prior spend of 1.5 million dollars we were able to move all sites and cover hosting in a single platform and cover it all 20% the cost. We not only realized cost savings to give dollars saved back to the business but was able to reallocate 2.5 FTEs worth of employees’ time onto other transformative efforts.

In addition, not only did we improve our hosting and patching automations, but we also enabled development pipelines from source control to have a controlled deployment strategy that went across multiple environments. This empowered a level of Quality Assurance testing and site monitoring we had yet to achieve.

Customer feedback: Our website editors and stakeholders were beyond thrilled to have only one editing experience to learn and use day to day. Our support teams were also happy, and our overall calls and reported issues were reduced!

Enterprise principles that supported my decision:

  • Consolidating competing CMS technologies allows for the management of a single platform
  • Leveraging a managed services platform allows a hands-off approach from development resources with ongoing maintenance; maintenance becomes core to the platform and is more easily managed
  • Developing your code within a source control platform allows for version management and prepares you to start considering your deployment strategies

Enterprise ROI savings can be realized by:

  • Retiring dedicated or hosting infrastructure
  • Reducing editor licenses in separate CMS systems
  • Removing extra 3rd party dependencies specific to an unneeded system
  • Removing unneeded external resources and/or support services costs to assist with troubleshooting
  • Leveraging your existing resources to be focused on new development and no longer in maintain mode

Regardless of your end decision on a specific product set to support your development team skillsets, one of the keys to drive repeatable enterprise development is to align decisions around simplifying management and driving automation of patching and version upgrades. CMS companies that thrive in licensing will nickel and dime you to bits on progress that you’ll never achieve with always fighting against yourself within their own products. If you’re not able to click less than 5-7 clicks to deliver a fully automated blank site to use, then reconsider your options. Make it a goal to center your platform decisions around their ability to leverage automation in how you can reduce unneeded activities. Automation will empower your staff to focus on new development.