Building an Enterprise .NET Applications Portfolio

February 4, 2016 by rdagumampan

At work, our main objectives in the .NET Architecture & Governance group is to manage risks and reduce the complexity  in the enterprise. We can achieve this thru due diligence, compliance, and informed decision making. To make an informed decision, we need to know where we are and what we currently have.

What we need is a comprehensive Application Portfolio (AP) where we can quickly get the application’s basic information, technology stack, architecture and operation attributes. An AP can be very useful:

  • When we need to estimate and kick-off a new project
  • When we need an internal reference architecture to serve as baseline architecture
  • When we need to tap an SME or experienced colleagues
  • When we need to roll out a critical release of components used in several applications
  • When we need to align applications according to Enterprise Architecture (EA) strategy
  • When a component or technology is threaten to be obsolete or unsupported like Silverlight or Flash
  • When we simply wanted to decommission apps because they became too costly to keep
Getting started For start, we defined our roadmap:
  • Phase 1: Application Information. Captures the basic attributes of the solution.
  • Phase 2: Technology Stack Captures the entire dependency tree of the solutions such as platforms, data store, communication, security, testing practices, nuget packages, architecture styles.
  • Phase 3: Maturity Analysis Analyze the solution based of multiple lifecycle factors
  • Phase 4: Automation Research tool for easier accessibility of the AP, automating analysis and dependency tracking
For Phase 1, we defined the ff application’s Basic Information (I have excluded the aux fields). This is just made in Excel Online document, shared across teams.
  • Common Name (CN)
  • Full Name (FN)
  • Description (DESC)
  • Business Area (BA)
  • Business Responsible (BR)
  • Technical Contacts (TC)
  • Product Owner (PO)
  • Scrum Team (ST)
  • Scrum Master (SM)
  • Lead Architect (LA)
  • Solution Architect (SA)
  • Release Manager (RM)
  • Infrastructure Delivery Manager (IDM)
  • Workspace (WS)
  • Source Code Location (SCL)
  • Solution Architecture Documentation (SAD)
  • Solution Infrastructure Documentation (SID)

When we started in Oct 2015, we have 130+ applications in our portfolio and it can be challenge get a strong commitment from different teams to collect the right information. I must admit, it’s not the most exciting task to scour those docs, chase POs and SMEs on top of their tight deliveries. It’s also a task in itself to keep this updated when key persons leave the company.

Early benefits We are so close to finish, and I hope to consolidate all teams into single AP this Q1 2016. We have seen early benefits when we have to answer where things are. We identified what solutions have not moved to new source code repository. We have identified solutions already decommissioned, those without any activity anymore, and those that didn’t reach production.

Next steps forward Meanwhile, we have initiated the Phase 2: Technology Stack. I think this is the most exciting part! I am working Arnis: a no-brainer dependency tracker for .NET applications. Arnis is available on Github and appreciate your contribution ;)

I will document our journey in this blog and hope you share how you do this in your company too.

© 2017 | About | Contact | Follow me on Twitter | Powerered by Hucore & Hugo