A State of Disconnectedness

In my last blog, I discussed how one might go about determining EA maturity.  I recently performed a self assessment of an organization I am working with.  We have a formal architecture function, we have standards written down, we have a review board and we conduct design reviews.  However, my own rating is a maturity level I will coin called "Level -1:  The State of Disconnected ness."  While we have a slightly mature EA process, it is not helping me to have conversations with senior management nor visualize the problems.

In order to answer a few questions regarding total cost of ownership, it looks like I need to access:

  • A Project Portfolio DB
  • A Business Process Management DB
  • A Configuration Management DB
  • A couple of dataset in the contracts and accounting department
  • A SharePoint repository where the systems architecture artifacts in Microsoft Office is located.
  • And a few more sources of data that hold our business goals, business functions and the services registry

Hence, I feel like I am in a state of disconnected ness.  This could form the basis of an argument for an EA repository, but I get to that one in a few weeks.

I promised earlier to propose where I might begin - even if you are also in a state of disconnected ness.  Does your organization have a master list of applications?  A couple of healthcare institutions we have been working with are quick to share diagrams of what applications are connected via the HL-7 integration engine.  These diagrams typically do not have all of the applications in the enterprise.  But they do identify a number of investments that are interconnected via HL-7 and would be a useful starting point.  The applications identify vendors from which we purchase licenses, how many users are licensed and the roles supported by the application.

So my proposal, maybe a dare, is for you to quietly start on your own to develop a list of applications found in the enterprise.  This is your anchor to help ground all the additional work you hope to do in the future.  Start by developing a consistent naming convention for the applications you collect and keep track of the synonyms you find throughout the organization.  If we don't have a consistent set of names, how can we gather data and develop reports in a reliable fashion?  This may not be that easy as I have found many "lists" available from different departments.  These lists need to be reconciled as a first step.

The next step would be to define application categories that are meaningful to the business.  You might do this by applications that support similar business functions (eligibility, enrollment, registration) or have similar characteristics (data collection, data dissemination, data evaluation).  Once you have your list, socialize it with other colleagues in your organization and see what they think.  You might just become a source of valuable information that others can rely on.

I'll talk about a few next steps in a future blog - "Doing more with your application list".



GF's picture