Analysing technology portfolio of an IT consulting company

Maintaining a technological portfolio of an IT company a similarly complex task as extending the portfolio with a new technology : Extending the technologycal portfolio.

Let we assume that we assume that a company has got the following technological portfolio: {t1,t2, .. tN}. Each technology in the portfolio has got a a certain cost to maintain and the maintaining the whole technological portfolio has got a cost as well. The cost of a certain technology depends on many factors, like the complexity of the technology, the available experts, how fast the technology is changing and so on. Cost of the whole technological portfolio depends on the cost of the individual technologies and the synergy effects of the different ones. As an example, maintaining a windows operation team and a .NET application operation team in a company has got a lot of common attributes, both due to the similar activities and due to the similar activity of operations. Let we assume that maintaining the technologies one by one would cost: {C1(t1), C2(t2), .. CN(tN)} and let we assume that cost of maintaining all of the technologies together would cost: Call (t1, t2, ... tN). A good technological portfolio has got the following characteristic:

ΣiCi(ti) > Call (t1, t2, ... tN) 

In other words maintaining the whole technological portfolio cost less than maintaining each of the elements one by one due to the synergy effects.

From the other perspective each technology brings some kind of a benefit, the most simple one that each technology or technological knowledge can be sold for a certain price. In this sense we can define benefit for each technology and a benefit for the whole technological portfolio. Let we assume that if we have the technologies one by one, the would bring the following benefits: {B1(t1), B2(t2)...BN(tN)} and let we assume that providing the whole technological portfolio together brings the following benefit: Ball(t1, t2, ... tN). A good technological portfolio has got the following characteristic: 

ΣiBi(ti) < Ball(t1, t2, ... tN)

In other words selling the whole technological portfolio together worth more than selling just the pieces one by one, As an example offering complex services ranging from SQL development via maintenance, operations and project management can be usually offered higher than offering these services only separately. 

Let we define the rentability of our technological portfolio as 

R(t1, t2, .. tN) = Ball (t1, t2, .. tN) / Call (t1, t2, ... tN)

Based on these definitions, there is a possibility to analyse out technological portfolio:
- at a rentable technological portfolio : R(t1, t2, .. tN) > 1
- at a nonprofitable technological portfolio : R(t1, t2, .. tN) < 1
- at introducing a new tN+1 technology in the portfolio, we make the optimal decision if : 
   R(t1, t2, .. tN) < R(t1, t2, .. tN, tN+1)
- Similarly by dropping out or outsourcing a technology, for example t1 from our technological portfolio we must be sure that :
   R(t1, t2, .. tN) < R(t2, .. tN)

Let we define benefits of alternative technological portfolios, that are manifested as we miss one technology from the portfolio, like if we skip only the t1 technology from the portfolio, we would get the following benefit function: 

Rt1 = R(t2, ... tN) 

- A ti technology is the strongest in the technological portfolio if missing the technology from the portfolio would cause the most loss in rentability : max ti (Rti)

- Similarly a ti technology is the weakest in the technological portfolio if missing the technology from the portfolio would cause the less loss in rentability: min ti (Rti) 

Extending technology portfolio of an IT consulting company

Working with small or medium IT consulting companies, it is always a question how exactly the technological service portfolio look like. What should be the major and what are the side-technologies that are covered. The situation is especially interesting as the whole IT world is changing each year, new technologies are emerging and others are getting old fashioned. 

The question that I try to analyse how is possible to make a decision about extending the current technological portfolio with a new one. For that question we investigate the market situation with the help of four different dimensions:

a. Cost of a technology: Every technology has got a cost. On the one hand, it depends on the complexity of the technology itself. The more complex it is, the more difficult to build up the necessary knowledge for that or more expensive to get the necessarily qualified expert for the given field. On the other hand, some technology are changing pretty fast, that means that simply keeping up with the everyday changes is itself a huge effort. 

b. Risk of a technology: The second big dimension is the risk of a given technology. It depends among the other on the technological life cycle. As an example if the technology is at the beginning phase in research and development, or it is practically used only by early adopters than the risk factor is pretty huge. On the other hand, general market situation should be taken into a consideration as well, like factors about competition and competitors or factors like general entry or exit strategy of the market.

c. Benefit of a technology: Certainly, the most important question, is a technology good for anything, does it provide value directly or indirectly for an end-user, is it possible to sell at all, or is it perhaps only a fashion trend or technological bubble.  

d. Combination of technologies: Last but not least, a new technology should not be considered only alone, it is usually an extension of the existing portfolio. As a consequence, it is an important question if there are any possible synergy between the new choice and the existing portfolio, either from a pure technological or from a rather market oriented point of view. 

The four big dimensions are summarized on the following picture.

Figure 1. Dimensions of a technology.

Based on the dimension there is a possibility to analyse certain technological choices or typical situations.

1. Successful portfolio extension: A typical characteristic of a successfully new technology can be seen on Figure 2. It must be good integrated with exiting technological knowledge,introducing the new technology should be easy and it should bring strong benefits. As an example, let we consider a company who mainly deals with windows server operation, choosing Skype4Business to extend the portfolio can be such a good extension: It can be good integrated both with the existing technological knowledge and with the typical customers as well, in this sense there are a lot of synergy effect on the market and the introducing cost is low as well. As it is a standard Microsoft product, the general risk factor is not too high; how much csutomer benefit does it exactly bring is certainly an open question.

Figure 2. Successful portfolio extension

2. Wrong portfolio extension: On figure 3 there is a typical example of a wrong portfolio extension. let we assume for instance that we have an SAP consulting company, that wants to offer Skype4Business for the customers. Well, firstly SAP is a totally different technological world, in this sense there will not be too many synergy effect, neither in existing knowledge nor on the market. It is again a question how much benefit Skype4Business offers for a customer.

Figure 3. Wrong portfolio extension

3. New strategical service: Figure 4 demonstrates a typical extension situation for introducing a brand new technology in the portfolio. It has got a huge cost and risk factor, the possibility to integrate with the existing portfolio is not so big, however hopefully it brings a lot of benefit as well. As an example, considering a company that mainly deals with .NET custom development, introducing Dynamics into the services portfolio can be such a direction.

Figure 4. New strategical service

4. Extending existing portfolio: Last but not least minor extension of the portfolio is a general case use-case as well. As an example consider a company that mainly deals with SharePoint, taking Office 365 into the technological portfolio is a trivial choice. The synergy effect is basically huge, the know how must be more or less exist, so setting up the new technology is pretty much straightforward. Such minor extensions are usually not result of a detailed analysis, rather a result of an indirect evolutionary process. 

Figure 5. Extending existing service

Notes on self adaptive SharePoint Environment

Recent trends in Data-Mining software solutions are going in the direction that data-mining and intelligent analysis solutions are getting cheaper and cheaper. It actually does not only mean the price of the software, but the ways of integration the different solutions are getting easier and easier as well. This provides new possibilities in the classical software and application development as well.

Having the possibility of collecting data about a running application, like application usage, logs, infrastructure data, and having the possibility to analyse them with data-mining tools, provide eventuelly the way of proposing a application improvmenet. Based on data measured and cheap data-mining possibilities a general SharePoint application development process can be defined as follows:

0. Analyse: This one is a classical requirement engineering step, analysing the requrements to set up an initial application. However, the requirements should not only be collected by interviewing the stackeholders, there is a possibility to analyse existing documentations or data, that might also be supported by data-mining. 

1. Setup: This is the classical step for setting up the system, planning and installing infrastructure components, developing and delivering custom solutions.

2. Collect data and usage: SharePoint collects pretty many data out of the box, like standard log files, search or usage and health data. As most of these pretty much infrastructure oriented it is important to measure data about certain application usage as well.

3. Analyse: The collected data has to be by different data-mining tools analysed.

4. Propose new structure: based on the data and analysis new application structure can be proposed. The improvement might be only infrastructure oriented to achieve a better performance, however completely modified use cases or business processes can be defined as well.

Repeat from step 1: The process can be actually repeated from the beginning, the new structure or can be again set up and the application usage can be again measured and analysed.

On the economy of server operation

From the economical point of view creating a new software is just like building a house. The only question is how fast, how cheap and which house is possible to build. The situation is pretty much different at classical server operation tasks like ensuring performance, having backup recovery or disaster recovery plans and concepts. This market is much more similar to the insurance market: One does not pay for getting a new service, but for ensuring that in case of disaster there is some recovery, backup or just simply the people who are capable of getting the system back. 

Notes on ERP and productivity increasing software programs

ERP and Productivity Increasing software programs were meant to help people on an everyday basis and increase the working productivity. Surprisingly the role of these software have been being slowly changing. As more or more business processes are defined and hard-coded by different software programs one usually has got the feeling that the company is basically managed and lead by these softwares and not anymore by humans. Perhaps in a not very far future companies will not be anymore defined by the people, by the employees, only by the used softwares and process. 

I always hated to say for people: human resource. However in this sense, it makes sense: human resource is just a resource among the others that is used by the company and probably not the most important one.

Notes on the Logic of IT Project Management

As in a normal communication there are two answers for a question :"yes", or  "no". In IT Project management there are usually three ones: "yes", "no" or "let we create an excel table". And surprisingly, the answer in most cases : "let we create an excel table".  

Integrating MatchPoint with SAP (a step by step initial approach)

Integrating MatchPoint with SAP is pretty easy as a first approach. You have to do two things: 

- get an SAP connector to read out some information from SAP

- implement a data provider in MatchPoint with the SAP adapter to use the imported data.

So let we have the steps in details:

STEP 1. Let we assume that we want to see the controlling area names from SAP controlling:

Figure 1. List of controlling areas in SAP.

STEP 2. Let we create some integration with SAP, there are many ways of doing that ranging from BAPI calls to web service integration through Netweaver. I m choosing the most simple SAP .NET connector. 

STEP 3. Let we create a Visual Studio project console application and reference the SAP.NET connecor dlls: sapnco.dll and sapnco_utils.dll. I am probably using a little bit old version, because for me it was working only with .NET framework 4.0 and not with 4.5 or higher. 

STEP 4. Let we create a basic connection class named SAPSystemConnectMP to store the SAP connection information, like port, system number, access information...:

    public class SAPSystemConnectMP : IDestinationConfiguration
    {
        bool IDestinationConfiguration.ChangeEventsSupported()
        {
            return true;
        }
        public event RfcDestinationManager.ConfigurationChangeHandler ConfigurationChanged;
        RfcConfigParameters IDestinationConfiguration.GetParameters(string destinationName)
        {
            if ("K47".Equals(destinationName))
            {
                RfcConfigParameters parms = new RfcConfigParameters();
                parms.Add(RfcConfigParameters.AppServerHost, "192.168.137.238");
                parms.Add(RfcConfigParameters.SystemNumber, "00");
                parms.Add(RfcConfigParameters.User, "root");
                parms.Add(RfcConfigParameters.Password, "***");
                parms.Add(RfcConfigParameters.Client, "800");
                parms.Add(RfcConfigParameters.Language, "DE");
                parms.Add(RfcConfigParameters.PoolSize, "50");
                parms.Add(RfcConfigParameters.MaxPoolSize, "100");
                parms.Add(RfcConfigParameters.IdleTimeout, "6000");

                return parms;
            }
            return null;
        }
    }

STEP 5. Let we create a wrapper class for the ControllingArea, with the static setup procedure that calls the BAPI_CONTROLLINGAREA_GETLIST Bapi and from the result takes the CONTROLLINGAREA_LIST table and lists all controlling area name and code.

   public class ControllingArea
    {
        public string ControllingAreaCode;
        public string ControllingAreaName;

        public static List<ControllingArea> getAllControllingAreas(RfcDestination destination)
        {
            List<ControllingArea> ret = new List<ControllingArea>();

            RfcRepository repo = destination.Repository;
            IRfcFunction controllingAreaList = repo.CreateFunction("BAPI_CONTROLLINGAREA_GETLIST");

            controllingAreaList.Invoke(destination);
            IRfcTable controllingAreas = controllingAreaList.GetTable("CONTROLLINGAREA_LIST");

            for (int cuIndex = 0; cuIndex < controllingAreas.RowCount; cuIndex++)
            {
                controllingAreas.CurrentIndex = cuIndex;
                ControllingArea area = new ControllingArea();
                area.ControllingAreaCode = controllingAreas.GetString("CO_AREA");
                area.ControllingAreaName = controllingAreas.GetString("Name");
                ret.Add(area);
            }
            return ret;
        }
    }

STEP 6. Let we implement a MatchPoint Data Provider, of course after referencing the MathcPoint dlls, possibly from the development kit : Colygon.MatchPoint, Colygon.MatchPoint.Server and Colygon.MatchPoint.Snow.

    [Serializable]
    public class SAPDataProvider : BaseDataProvider
    {
        public string[] List;

        public override BaseDataProviderInstance CreateInstance(string cacheKey, IEnumerable<string> columnNames)
        {
            return new SAPDataProviderInstance(cacheKey, this, columnNames);
        }
    }

STEP 7. Last but not least let we implement a data provider instance. Perhaps the most important part of the instance is the GetInternalData function. It opens an SAP connection through the configured connection class, queries all the controlling areas and transforms the names to a simple string list.

   public class SAPDataProviderInstance : BaseDataProviderInstance
    {
 private readonly SAPDataProvider provider;

 public SAPDataProviderInstance(string cacheKey, SAPDataProvider provider, IEnumerable<string> columnNames) : base(cacheKey, columnNames)
 {
  this.provider = provider;
 }

 protected override CachePolicy CachePolicy
 {
  get { return new CachePolicy(CacheGranularity.NoCache, 0); }
 }

 protected override IEnumerable<object> GetInternalData()
 {
            SAPSystemConnectMP sapCfg = new SAPSystemConnectMP();
            try
            {
                RfcDestinationManager.RegisterDestinationConfiguration(sapCfg);
            }
            catch(Exception ex){}
            
            RfcDestination rfcDest = RfcDestinationManager.GetDestination("K47");
            List<ControllingArea> cAreas = ControllingArea.getAllControllingAreas(rfcDest);
            List<string> res = new List<string>();
            foreach (ControllingArea area in cAreas)
            {
                res.Add(area.ControllingAreaName);
            }

            provider.List = res.ToArray<string>();
            return provider.List;
 }

 public override string GetCacheToken()
 {
  return null;
 }
    }

STEP 8. Having compiled,we have to registrate everything in GAC (the SAP connector DLLs as well) and we have to registrate the DataProvider in the matchpoint configuration as an external assembly and of course IISreset at the end.

Figure 2. MatchPoint Configuration.

STEP 9. If everything went well, you have to see the new dataprovider in your system. So as an test we can create a composite WebPart setting the SAPDataProvier and showing with a pattern transformer the DataItem.

Figure 3. Composite WebPart configuration.

STEP 10. If everything wen well, you should see the list of Controlling Areas directly from SAP.

Figure 4. Controlling area information in MatchPoint from SAP.

The ways of customizing a software

Previously I always had the opinion that there are basically two ways of software development:

 - having a project based development, starting by a business analyst to gather the requirements, setting up the architecture, making an implementation and delivering to the customer, or

 - creating and selling a ready to go product, starting by a product manager, having some implementation phase and then selling at the end. 

However the world as usual is more complicated. 

I am making analysis based on how much a product is possible to be customized from an end user perspective, having an analogy through the different restaurants and fast food restaurants. In this sense I would at least distinguish the following four types of software products:

  

1. Ready to go products

Ready to go software products are like sandwiches in a supermarket. You can buy them as they are, you can usually choose between different sandwiches, however you do not have the chance change the product itself, like having your sandwich with mustard and mayonnaise, instead of ketchup.  

Figure 1. Ready to go product.

Typical "ready to go" software products are the different mobile and or SharePoint Apps. They provide some very specific but limited functionality, they usually specialize on the B2C customer segment and both the buying and the installing mechanism are as automatic as possible, as an example via online stores.

2. Complex Products.

Complex software products offer more space for customization, despite they are products for a very specific need. They are like ordering a menu at Mc Donald's, you already have some possibility to customize your menu, varying several parameters, like french fries or salate and of course you can choose if you want to have mayonnaise, ketchup or both.

Figure 2. Complex Products.

Such complex products are usually the domain specific business applications, like quality management system, special applications for transportation, financials, logistic and so on. The avrage complexity of these software systems are usually bigger than to be only self-service, as a consequence buying these products requires a certain level of consulting. As a consequence they usually sold in a classical way instead of online shops, and with a certain level of consulting services as well.

3. Frameworks.

Frameworks are actually not products, however they are certain way of conveyance chains that are capable of many different, slightly different products. The best example is subway, there is actually a pretty complex customizing process that help to deliver a couple of thousands of slightly different sandwiches in a pretty efficient way.

   

Figure 3. Frameworks

Such software frameworks are for example, the different BPM and workflow solutions, like K2 or Nintex in the business field, they do not provide ready to go solutions, instead possibilities to build up many different customized processes. Actually SharePoint itself can be regarded as well as a general framework for delivering social collaboration solutions. Buying and installing these solutions usually splitted into two parts: buying the framework itself and buying the consulting service for that.

4. Custom project development

Project development is the very classical way of software development, with business analyst, requirement engineering and then implementation and delivery. It is like a five star restaurant, where you have a small discussion with the waiter discussing your taste, the possibilities and then getting you burger exactly as you want.

.Figure 4. Custom project development.

On IT and SharePoint market segmentation

It is interesting to investigate both the IT and generally SharePoint market as well based on the following two dimensions: Market segment and customer flexibility (Figure 1). 

Figure 1. SharePoint market segmentation based on market segment and customer flexibility.

Market segment is basically the standard dimension that is usually described, we can scope from a simple business to customer market to a different business sizes ranging from small business to the enterprise.

The second dimension is perhaps a little bit less standard. It describes how much flexibility do we want to provide for our customers. The simplest way a basic product, that provides some functionality without a too much customization or extending possibility. It is like, if you buy a packed sandwich in a supermarket, you can choose which one do you want to buy, you can not really pack out your sandwich and fill with mayonnaise instead of ketchup. 

The next stage is products with the possibility to heavily customize. They are like eating sandwich at Mc.Donalds, you have the possibility for some variation or customization, however the possibilities are limited. But you can surely choose if you want to have an extra polonaise or ketchup.

Frameworks are not actually 100% ready products but some general building blocks that help you deliver a lot of different products in a fast and efficient way. It is like Subway, you do not really have ready sandwich,  but rather a coupe of basic foods and processes that help you to get a ready sandwich. 

Of course, the last stage is to have fully customized project, you can precisely describe each part of your product. It is as a 5 star restaurant where you can have a small appointment with the chef, describing what kind of a sandwich do you want to eat.

Certainly the bigger customer flexibility means as well that more preparation, more professional stuff are required and of course the whole process can be less automated. As a consequence more customer flexibility implies an increase in cost, so it is not surprising that IT provider companies offering more flexibility to the customers concentrating rather on the enterprise segment.

The SharePoint market can be characterized this way as well: 

- IT companies having small boxed products selling the product mainly as cloud solutions with self service buying possibility and primarily on the B2C market. Typical examples are SharePoint apps.

- As soon as a product has got a a bigger range of customization possibility a certain amount of consulting and pre-sales activity is practical to be delivered as well. Despite the product can be cloud hosted, but the whole sales process is not based on an online shop on a "buy if you want" basis. Such products are for example special Outlook or Mobile components that communicate somehow with SharePoint. 

- It is difficult to distinguish between a product and a Framework. I would say as you are having more and more possibility to customize, more and more possibility to further develop than it is better rather to speak about a framework than a product. The best examples are BPM frameworks like Nintex and K2, however SharePoint itself can be regarded as a general collaboration framework as well.

-  If everything has to be newly invented and developed, than it is better to speak about a 100% custom project. Certainly such projects are pretty much time and resource intensive: time and resources are required for specification for testing and quality for project management and so on. As an example .NET development from scratch can be regarded as custom project. 

Notes on SharePoint hybrid environments

Considering the new directions of SharePoint from Microsoft, I would note a couple if things:

- Building up hybrid technologies (partly cloud, partly on-premisse) makes SharePoint environment more difficult as ever. You do not only need SharePoint infrastructure, developer and business consultants, but cloud infrastructure and development experts as well.

- I am not sure if it provides a real value for an end-customer. I mean, a standard user needs some IT functionality that runs stable if it is on the cloud, on-premisse or hybrid does not really matter, at least not from end user perspective...

- From an internal CIO perspective having a hybrid environment does not necessarily make sense, actually with a hybrid environment you have both the problems of the on premisse and the new challenges of the cloud. Despite it perhaps make sense having a hybrid environment if there are some motivations to outsource only part of your IT infrastructure, like  for security reasons, or simply because clound is simply too new and perhaps too risky.