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.

Fundamental or qualitative analysis on the IT market

"Fundamental analysis, in finance, is the analysis of a business's financial statements (usually to analyze the business's assets, liabilities, and earnings); health; and its competitors and markets. When applied to futures and forex, it focuses on the overall state of the economy, and considers factors including interest rates, production, earnings, employment, GDP, housing, manufacturing and management...." - source WikipediA

Certainly IT market is a little bit different from the general financial market, despite I think it makes sense to speak about fundamental or quantitative analysis on an IT market as well. Let we imagine the following situation: we have a company that provides different IT services for different customers. The first is to identify is the service portfolio to be offered.

Service portfolio: considering an IT company it provides special services to the customers and from the possible services they create revenue. The service portfolio usually contains some of the following major sources:
-   License Business: like reselling the product from another vendor for a certain marge.

-   Consulting : in the sense of either Business consulting or Technology consulting.

- Training: Training can be related from classical end-user training, to a more deep dive infrastructure, customization or development oriented training. 

-  Projects or project development: means setting up end user use-cases with a small team of software developer, infrastructure experts, project managers and business analysts, 

-  Product development: setting up and bringing to the market individual products based on a given technology can be part of the service portfolio as well. It usually requires software development teams, product manager, sales and marketing experts.   

The portfolio categories can certainly be fine tuned considering a specific company. As an example let we say we have a small company creating a specific product. It implies that the company will have the most revenue from the product development source and perhaps a little bit from specific consulting and training service that are related to the specific product. 

Market event: Technology is changing practically every day. New solutions and platforms and trends are emerging and old ones are withdrawn. Typical market events might be the followings:

- New IT Trends: like cloud computing is being more and more popular. 

- Platform and technology changes of a "big player": like Microsoft announces a self service BI platform.

- Legislation changes: like changes in the direction that certain companies are allowed to store certain private data only locally or in the cloud as well.   

Forecast: The major challenge is to identify at fundamental or qualitative analysis how certain market events influence the general service portfolio. Certainly it is pretty much different to create exact figures, however the direction can be certainly pretty well identified. Examples are the followings:

- Cloud computing trends imply a decline in all of the infrastructure oriented services: like Infrastructure consulting, Training related to infrastructure topics and infrastructure parts of projects.

-  Having a new user friendly user interface usually implies that the new interface has to be learned once again. It implies an increase in the Training services. 

- Introducing self service IT from a "big player" usually implies a decrease in the classical IT consulting services revenue. It is a little bit more difficult question how it behaves on the project development part, as most self service IT, is self service only till a certain technology limit. If the limit has been reached, usually hard core development competence is required to develop use cases.  

Notes on IT markets and partner markets

Perhaps it is surprising but a market growth or a market change of a big software vendor like Microsoft does not necessarily means market opportunity for the partner companies. Partner companies concentrating on the technology of big vendor usually make profit from the following sources:

  -  Reselling Product.

  -  Consulting services of the given technology.

  -  Project business: delivering changes or new functionalities for a customer.

  -  Product business: delivering products based on the technology for many customers.
  -  Training.

As some new innovative technology from a big vendor like Microsoft certainly produces a business growth for the vendor itself, it is not so sure how it produces business for the partner network. Examples are the followings:

  -  Innovating the basic technology very often implies that the partner products have to re implemented pretty often, It is certainly a question if it can be done profitable and if the end-customers accept the increased maintenance cost. 

  -  Setting up self-service functionalities certainly implies a decline in the consulting or the reselling market of the partners,

  -  Making only cloud services implies that the infrastructure consulting and services of the partner companies are being vanished.

  -   Focusing on products instead of frameworks implies that the project business of the partners will be decreased.
  -  New functionality or new user interface means increased training business possibilities for the partner companies.

Certainly there is chance to reinvent the partner business itself. Like one example might be to create disposable applications so reinventing the basic technology will be not such a huge problem, as the disposable application won't live so long. Although here is for example a question if Microsoft relative highly-prized positioning is really the best way to create such a disposable applications. 

Corporate finance summarized

If you ask from an unknown person for 10 euro, you are regarded as a beggar.

If you ask for 1 million, you are regarded as serious business man.

Software development methods compared

Let we compare the different software development models based on two dimensions, communication cost and delivery time.

Communication cost: this dimension summarizes how much effort must be taken into account to cover all of the communication during a software delivery. The dimension contains on the one hand elements like communicating with a customer, creating specifications, changing specification elements, coordinating the technical delivery, like for example with hosting companies and so one. On the other hand, communication means communicating with the development team internally. As thumb of rule, if part of the development team is offshore, there is surely an increased communication cost due to the intercultural, langue differences or simply because of the distance.

Delivery time: is the time, how fast can be deliver either a ready or a prototype solution for the customer. 

The following picture demonstrates the two dimensions and the proposed software development methods.

Figure 1. Software development models based on communication cost and delivery time

Let we suppose that the communication cost should be kept low, be for instance the customer does not have very much time for creating a specification or taking part each day in different stand-up meetings. In this situation, if we have to deliver something pretty fast, than the only possibility is a ready product. Supposing that the software solution does not have to be delivered very fast, but the communication cost should be despite kept low, than we can use the classical waterfall, V and W models. 

The other way, if a highly increased communication cost is accepted by the customer and in the team, like having a lot of meetings changing and redefining the specification or the scope of the project, Supposing that the delivery time should be fast, than we can use the different agile methods, like scrum. The last segment, in which the communication cost is huge, despite the delivery time is pretty slow is typical for the research and development projects. In these projects, the typical situation is "we do not know what, we do not know how". 

  

Notes on SharePoint Apps versus SharePoint Addins

Recent change from Microsoft that SharePoint Apps will be renamed as SharePoint Plugins. As it is theoretically only just a new name, despite it is interesting to a look which name describes the technology better. 

App Framework for mobile devices means something in the direction that you have a got a basic framework, that is the core mobile device. It is extended in a couple of directions by Apps. The basic Framework provides among the others the following services:

  - Framework and access to the touchscreen
  - Phoning
  - Data Transfer
  - Geo location service
  - Access to other hardware devices
  - ....

The idea is pretty much similar to the standard operation systems and applications. The operation system provides most of the core functionalities and the applications simply extend these functionalities. The core functionalities are for example the followings:

  - Access to the file system

  - Access to IO devices
  - Memory management
  - CPU Resource management
  - ...

As a consequent, if we speak about SharePoint Apps, we would expect something similar, a core framework that is extended by the SharePoint Apps themselves. So the question is what should be regarded as SharePoint basic functionalities. Having more than 6 years SharePoint development experience I would say that at least the following elements should be regarded as SharePoint core services:

  - Integration on Authentication

  - Integration on Authorization

  - Workflow integration

  - Data model integration, like standard Lists and extended data model elements.

  - User interface and design integration

  - Integrated operation model, like integrated logs or monitoring 

  - ...

Some of these functionalities are covered by the SharePoint hosted App model, however almost none of them are realized by a provider hosted App. Provider hosted App model realizes only the integration of the Authentication, everything else has to be developed from scratch, like building up ta SharePoint like user interface, realizing the same authorization model or developing web services and custom activities for workflow integration.

As a conclusion, a SharePoint hosted App might be called really as an App, but for a provider hosted App the name is surely pretty much misleading. One would expect a model and core functionalities that do not exist. In this sense AddIn is probably a much better naming choice.

  

cloud versus on-premise compared based on technology curves

Licensing model and cloud model might help to reduce the initial setup cost of a certain technology. As at setting up an on-premise environment and buying server license implies a huge cost and setup time, buying cloud pro user license definitely means a reduction in setup time and cost. Certainly the situation is not so simple, as on the one hand a user license based model can be more expensive on with a given number of users, On the other hand  the extension possibilities of a cloud model are usually more limited as with an on premise environment, meaning that the technology limit can be reached more easily. 

Set up time and cost (before Q1): Set-up time and cost are definitely much faster on a cloud environment.

Effective agile development (between Q1 and Q2): considering most software as a service cloud environment, the provided services are usually much more limited as on the on premise versions. Cloud soft wares are much more 'boxed' products.

Architecture limit (after Q2): Architecture limit can be much more easily reached on a cloud software as a service solution. Hence if the limit once reached there is much less possibility to create some extensions, if there is at all the possibility to create extention. 

As conclusion, a cloud based user license environment is certainly much faster and cheaper on a short run, however not necessarily the best choice on a long run.   

Figure 1, Cloud versus On-Premise compared base on cost-use-case model.

Cash flow models in software development

SharePoint evolution: from platform to product

Introduction.

It is pretty interesting to see the current evolution of SharePoint from an agile technology curve perspective. Briefly speaking if we consider a classical software project where we deliver services to a customer in a certain time frame, most project have got three typical phases:

1. Set up: most technology requires some kind of a setup phase, like installing the software, setting up the basics for the environment and usually buying licenses. This phase can be characterized with  increased efforts (setting up effort and license fees), on the contrary relative few direct user requirement are covered. This phase is typically realized by infrastructure teams.

2. Efficient agile phase: in this phase user requirements can be delivered fast and efficient. Use cases that are delivered here can really be regarded in an agile way, like without explicit specification, consulting with the customer on a daily basis, having sprints and delivering use-cases on a weekly basis. This phase is typically realized by small project teams of consultants and developers, usually working on site at the customer.

3. Architecture limit: Once the architecture limit has been reached further use-cases can only be delivered for a huge cost, usually needing to extend the architecture itself. In this phase agile cooperation can not really be efficiently supported, instead classical requirement engineering and product development are required. 

Figure 1. General Agile characteristic.

Platform versus product.

Comparing a classical product with a rapid application development framework from the agile technology curve there are major differences. Firstly setting up a product means delivering a lot of end-user functionalities as opposed with a framework where setting up usually means only a minimum scenario usually without covering too much end-user requirements.

Secondly, a product offers limited possibility for efficient agile development. There is certainly some possibilities to set some parameters but the situation can be very easily reached where the product itself has to be further developed, A rapid application development  framework is however planned to realize a long effective agile phase in which user requirements can be fast and efficient realized. 

From the architecture limit point of view there are not too many differences. If the limits reached than either the product or the framework itself has to be further developed that practically means slow and hard core software development.

Figure 2. Product versus framework compared.

Briefly formulate a framework is usually a general application development framework on which you can realize a lot different user requirements in an agile way with the help of a some IT consultants. A product is practically something ready, if you like it you get from the shelves and pay at the cash desk, if you do not like it, you look for another product. Extending the product itself usually realized only by the product manufacturer.

    

SharePoint evolution.

The last couple of years of SharePoint development was more or less going very strongly to the direction of Office 365. Even if there is still at least one version on premise, this version supposed to be similar with the cloud one. Besides, it seems that on a long run more or less the Office 365 will be the standard perhaps only on the cloud.  

From an infrastructural point of view Office 365 is similar to a normal cloud solution, it is practically a product. You have a couple of well defined services that you can order and buy right away and after some configuration the set up phase has been delivered. As it seems to be a good thing for the first side, however it is more or less the one size fits for all principle.You can build up perfect data models based on lists and document libraries supposing that you did not reach data view limit however as soon as you have reached there is gonna be difficult to extend, you are practically at the architecture limit Certainly provider hosted app and storing everything in an Azure database is a possible way, but then you should consider implementing the provider hosted app, the logging mechanism, the user interface, the integration of standard Office365 lists, search and workflows... it is a lot of work for practically zero functionalities. On the contrary with a classical SharePoint on premise environment there are some possibilities , like extending the data limit on the central administration, integrating BCS with SharePoint Designer and SQL Database, having some Visual Studio Development and developing BCS with like Oracle...

Similar limits are to banning the public pages, constraints on the cross site information, problems on the brand new workflow and so on.   

On the other hand the agile phase is definitive smaller at Office 365. There are smaller number of possibilities that one can click together, like the missing cross side or public page features. Hence the development styles are much more limited as well. Farm solutions are definitive missing, sandbox as well, as a consequent developing fast and efficient backed functionality is already not possible. Customization on the design or javascript side is still possible, however on the one hand only a limited number of functionality can be delivered as on a pure javascript basis, on the the proposed delivery way is to build an App that can be sometimes pretty much resource intensive. As soon as something more is required the only way is to implement a provider hosted App, however implementing a rpovider hosted App from scratch is pretty much resource intensive, one should consider implementing apart from the core functionalities, logging, SharePoint integrated user interface, SharePoint integrated data model, workflow and search integration. Such a development has got very much the characteristic of being outside of the agile phase: the development is slow, the requirements can not be changed too often, it is usually can not be sold in one project but the development has to be financed by several customer.

Conclusion.

Based on the agile characteristics it seems that SharePoint is appearing more or more in the direction of a product and not as a rapid application framework. There are a certain number of predefined components that you can by and configure but if your requirement is coincidentally not supported than you can buy another product or practically finance platform extension. Actually the naming conversion shows this direction as well: it is already Office 365 that implies that SharePoint is a similar product as Word, Excel or PowerPoint and not a Rapid Application Framework. Similarly future names of App are actually AddIn-s that also points into the direction of rather being a Product as a framework.

IT sales channels compared

IT sales channels compared....

Comparing RAD with App model based on agile technology curve

Another comparison based on the agile technology curve is to compare a Rapid Application Development Framework with an App Framework. As App framework we consider IT platforms like mobile phones on which several Apps can be individually installed or uninstalled. Certainly not only mobile platforms exist as App platforms, for example Business App platforms, like Odoo exist as well.

Set up time and cost (before Q1): Regarding on set up the RAD and APP platform are pretty similar. Installation takes some time, license cost, despite relative few end user functionalities are delivered.

Effective agile development (between Q1 and Q2): Effective agile development phase is pretty much different. As RAD framework provides a long effective agile development phase in which use cases can be delivered pretty fast, App framework works rather as a number of independent products. You can install each app, which practically means a small set up phase, than the app requires some configuration steps. For covering a new use case, usually new App has to be installed which means once again a small set up and configuration phase. 

Architecture limit (after Q2): If architecture limit reached, the use cases can be delivered only with a lot of efforts. In case of App framework, usually the problem is that the Apps are independent from each other. As a consequence the architecture limit can be fast reached if cross functionalities between the installed Apps are required. Certainly the following picture is only a demonstration and shows the general characteristic of the two approaches. If a certain set of use cases can be delivered faster or cheaper by a RAD framework or APP model is dependent on the certain technologies and use cases.

Figure 1. Comparing RAD with App model based on agile technology curve.

Comparing ERP with RAD based on agile technology curve

Agile technology curves provide the possibility to compare typical characteristics of different systems, like a Rapid Application Development (RAD) and Enterprise Resource Planning (ERP). 

Set up time and cost (before Q1): The major difference is that setting up a RAD system is usually much faster cheaper and much cheaper than with the ERP. However a RAD system provides not too many ready components. On the other hand setting up an ERP system is usually pretty much time consuming and the licenses are usually not the cheapest ones, but many pre-configured component and functionalities are delivered.

Effective agile development (between Q1 and Q2): A RAD system usually has got a pretty long effective agile phase, in which use-cases can be fast and efficient delivered. ERP system however works with a lot of half-ready components so they usually provides a smaller agile phase in which the components are configured.

Architecture limit (after Q2): If architecture limit reached than both in a ERP and in a RAD system delivering a new use case will be difficult. For an EPR system, the architecture limit can more or less be reached if the use case can not be delivered by configuration but hard code development scenarios should be used. Certainly it is generally difficult to say if the architecture limit is better for an ERP system or for a RAD, so the following figure provides only a demonstration. Similarly if certain uses cases can be faster or cheaper by RAD or ERP delivered are situation and technology dependent, the following figure shows only the basic characteristics.  

Figure 1. Comparing ERP with RADbased in agile technology curve.

Technology curve for Agile development à la technology extention

Sometimes the situation is not so simple that one technology is used overall in the project, despite the project starts with one basic technology and extended in the middle with another one. As an example as we start a project with a standard SharePoint development and as the use cases are being evolved we decide to cover some of the functionalities with a modified architecture, SharePoint and Nintex installation. It practically means that in the middle of the agile project there is a peak, a secondary set up time as we practically install Nintex. That practically means that we should consider in the future the mixed technology curve of the two different technologies. For example in this case it implies that the effective agile development phase is much more extended, in other word technology limits will be reached later. 

Figure 1, Agile curve for technology extension.

   

Comparing SharePoint on premise with Office365 based on agile technology curve

Agile technology curves provide the possibility to compare a SharePoint 2013 on premise scenario with an Office365 one. 

Set up time and cost (before Q1): Set up time with Office365 is pretty fast, one has to order the applications and functionalities and everything is ready in minutes. Supposing an on premise SharePoint scenario, everything has to be installed from scratch that takes of course more time. From the licensing point of view usually Office365 is cheaper than SharePoint.

Effective agile development (between Q1 and Q2): From an agile development point of view the two solutions are pretty much the same at the beginning phase, there is a possibility to deliver very fast standard configuration elements like lists webparts or document libraries, it is a little bit more difficult to configure html, css or javascript elements.   

Architecture limit (after Q2): The main different is the architecture limit. With SharePoint 2013 on premise there is still the possibility to extend the framework or integrate external systems with farm level development, sandbox, business connectivity services or custom service applications. Considering Office365 most of the framework extensions are  simply not possible; the only way to realize some extension is to develop a provider hosted App, which requires a high expertise and can not be carried out very fast. 

Figure 1. Agile technology curve of Sharepoint 2013 on premise and Office 365.