Let’s face it. On premises system architectures have long been an enabler for both lazy and amateur enterprise architects. Need to move some data around? Simply add a couple of fields to store it. Need to add some integration just so we can see all of the data in a single place? Build some batch jobs to push data hither and yon – and replicate it in multiple places just to make it easy to get at.
Nowhere is this more evident than in a Project Management Information System (PMIS) that has grown organically to the needs of the enterprise. Invariably, a PMIS has grown as a collection of disparate systems and silos, all oriented to the needs of a specific functional group that may be involved in the execution of a project.
The integration eventually evolves into a veritable spaghetti diagram of lines moving data from one system to another. Often, the data schema for the scheduling tool is expanded or repurposed to collect all of the data into a single, convenient data repository. Generally speaking, this sort of works for many organizations. They still manage to get their work done, albeit with a fair bit of grumbling around project managers having to access multiple tools to get their jobs done.
The main challenge with this tool architecture is that it doesn’t support a nimble process framework. As PM processes mature (pro-tip: they will) or adopt to the changing organization, the organization needs to maintain a strict focus on a capabilities infrastructure. As the capabilities develop in maturity, the underlying tools must also adopt, and this is where the traditional organic PMIS fails…..to a large extent due to the technical debt incurred in the evolution of the overall system.
Traditionally, with on-premises systems, this tendency towards entropy is addressed every couple of years in the form of an upgrade. The vendor releases new versions of the software, and as part of the inevitable upgrade process, the organization performs a subbotnik to reassess and simplify the overall system. This cycle naturally prevents the overall system from getting too complex.
Today’s subbotnik is not your father’s subbotnik however. Today, most of the discussions we have around upgrades involve a consideration of moving to the cloud. Often times, this is driven by the desire to take advantage of the cost savings that enterprise cloud offerings now bring to the table. Twice in a week, I’ve been in conversations with clients about how they could save significant infrastructure overhead costs through moving to the cloud – but have been prevented from doing so by the architecture of their existing PMIS. This means that they’ve been stuck with expensive on-premises environments with feature sets that grow increasingly outdated with each day.
Furthermore, additional care must be taken when moving to the cloud as we will lose that convenient safety valve of reassessing the entire thing from the ground up as part of an upgrade within the next several years. Whatever we design today, we will have to live with tomorrow – and the day after tomorrow.
Over the course of multiple discussions, the architecture I see evolving around the PMIS looks a lot like this:
Instead of pulling data backwards and forwards, we are consolidating it. The data is either consolidated in real time with any number of reporting tools such as Microsoft Excel, PowerBI, Tableau or Spotfire…..or it’s being pulled into a data warehouse such as SQL or HANA using an ETL tool. Doing so greatly reduces the complexity of the overall system and allows each part to feed data in such a way that the company can rapidly mature in a specific capability as needed.
Hence, for those organizations with a significant existing investment in on-premises PMIS and the associated integration that this usually entails, a cloud discussion almost always needs to start from the process discussion. What is your process? How do the tools you currently have enable this process? How do the tools we currently have block the process? Does the process truly support the project management needs of the enterprise? It’s only after having this discussion, that a new system architecture may be designed…..one which enables the nimble enterprise.
Here, we run into some of the typical challenges of a cloud discussion. Typically, the cloud agenda is part of the IT agenda – as a means of reducing operational costs associated with maintaining rooms full of big iron. The processes we are supporting are owned almost always by a PMO or PMOs. To have this discussion effectively, i.e. of how to move to the cloud, the PMOs must be engaged by IT to reassess process and ensure that the results can be moved to the cloud effectively and efficiently.
Prior postings on architecting a PMIS (here and here)…..and a couple of posts on mapping EPM tools to process architecture (here and here)