Skip navigation
All Places > CA Unified Infrastructure Management > Blog > Authors Jim.Perkins

It may have been me who said it, or a host of other individuals, but if you are reading this post, I would presume that you are someone interested in discussing this topic.


We’ve been talking about it for a long time, but the transition from running applications on premises to the cloud is most certainly underway.  Many organizations have implemented a SaaS-first policy for evaluating new applications.  Even their existing applications are transitioning from private cloud into the public cloud, and the administrators of these applications need a way to seamlessly monitor their infrastructure as they make these transitions.  These changes aren’t easy, and we need solutions that help us simplify the process.


This transition to SaaS and he cloud is happening because organizations are beginning to see the value of letting the experts manage your applications, the upgrades and the infrastructure that hosts them.  Especially solutions like CA Unified Infrastructure Management. 


Therefore, we are working on CA Unified Infrastructure Management SaaS (“UIM SaaS”) to help our users simplify the move to the public cloud.  CA UIM SaaS has the capability to help you monitor both your public and private cloud infrastructure.  As you transition your infrastructure to the cloud, you don’t have to rely on separate monitoring solutions.  You can monitor both with CA UIM SaaS!


I am looking to meet with individuals who are interested in learning more about the future of CA UIM SaaS.  I am looking for users who may meet one of the following criteria:

  • You are under a corporate mandate to transition to SaaS-based solutions of your infrastructure management needs
  • When it comes to infrastructure monitoring, you need to follow a SaaS-first strategy
  • You are a current user of other CA DevOps products like CA APM.


If this sounds like you, or you are interested in learning more about CA UIM SaaS, please comment here, or send a private message to myself (Jim.Perkins), or Raj Sundaram ( sunra05 ).  We will then get back to you directly.

Please don’t get mad at me, but you won’t find a roadmap with dates anywhere in this blog post.  If you came here it may be because you were searching the community looking for just that: The latest UIM Roadmap including dates.  Well, the truth is, you won’t be able to find that here, or anywhere publicly for that matter.  I am sorry about that, but if that is what you are looking, I suggest you keep reading.


Please understand. It’s not that a UIM roadmap doesn’t exist.  It most certainly exists.  In fact, I’m looking at one version of it right now.   Product managers are all about the roadmaps.  We study them, change them, add and subtract from them as a regular part of our job.  Roadmaps in CA drive the priorities of engineering.


Roadmaps are not only necessary inside CA Technologies; they can be an excellent sales tool.  Future customers often want proof that CA is committed to a particular product, and we have a long-term vision for making it even more valuable.  As for current users, there is great value in knowing what features are coming and when you will be able to get them.  After all, many product users have roadmaps too.


However, the product managers are not permitted to share roadmaps outside the company, except in controlled situations.   I don’t think there is a short version to the story as to why this is the case without sounding like I am blaming other people, so I will do the best I can to keep this long description on point.


Much of how publicly-traded companies behave is driven by the United  States Generally Accepted Accounting Principles, or US GAAP for short which is audited by the companies external auditors and submitted into the SEC (securities and exchange commission)   There are numerous examples in the history of the stock market where a company failed to follow US GAAP and and that mistake led to financial statement restatements.


One small but significant part of US GAAP has to do with revenue recognition; in this case revenue recognition from the sale of a software license.  When software is licensed to a user, the revenue must be reported to shareholders.  One very important factor in reporting revenue is the quarter in which the revenue was earned, or “recognized.”  (If you want some in-depth reading, you can go to the Financial Accounting Standards Board (FASB), and read more about Software Revenue Recognition)


According to US GAAP, software license revenue can be recognized when all the terms of a licensing contract have been delivered.  If a customer makes a buying decision based on a future release of a feature not currently in the product, then the vendor cannot recognize that revenue until that feature is delivered. 


Therefore it is important that CA Technologies control the distribution of dates of when specific features will be released.


CA Technologies is not alone in its policies of controlling the distribution of roadmaps.  Other publicly-traded companies are required to do the same.  At CA Technologies, we have External versions of the roadmap we can share to customers individually but they also do not include dates.  No roadmap is published on an open website, like in a community thread or blog post.  After all, roadmaps are no-business of our competitors either. 


In conclusion, if you need to know what we are up to on the product, you need to reach out to a product manager directly, and they will schedule a meeting with you where such matters can be discussed individually.  Arrangements can be made to share a roadmap if there is no risk of impacting revenue recognition.

A casual observer of this community will notice that there are quite a few members that refer to themselves as “product managers.”  Sometimes the product managers refer to themselves as product owners.  From the perspective of the community, they are one in the same.


I would like to share some background on the position to help users in this community understand what they do on the development team and why interfacing with the product managers is very valuable to the members of the community.


The UIM software development organization is quite large.  The organization is broken into smaller teams, sometimes referred to as “scrums”.   The teams are led by a group of three managers; we call these managers collectively a “triad.”  A triad is made up of an engineering manager, an architect, and a product manager.  Each triad will lead one or more development teams, and they are usually embedded directly in the team, sitting with them in the same room.


The engineering manager is responsible for managing the software developers, and owns what we call the “When”.  The “When” is short for “When will the product requirements be delivered?”


The architect is responsible for the “How”.  The “How” is short for “How will the requirements be implemented in the product?”


Finally, the product managers are responsible for the “What”.  The “What” is short for “What are the requirements, and what are their priorities?”  The “What” is communicated to the development team primarily through use cases.  Use cases describe who is using the product, what that user needs to do, and why it is valuable to them.  Product managers are all about the use cases.  The use cases drive the design by the architects, and the implementation by the engineers.


Knowing all of the uses cases is one of the greatest challenges faced by product managers.  The best product managers admit this fact, and know they must interface with the users as often as practical to capture previously unrecognized uses cases.


Therefore, the community is vital to the product managers and helps them to capture use cases directly from the users themselves.  Community members, who are able to effectively communicate their use cases and influence the product managers to work those use cases into the development plan, are some of the most powerful members in the community.  Those influential members have successfully opened the most direct channel available, strait to the developers themselves.