Notes on Software Project Management

Having spending a decade with different software projects and development methodologies, I would conclude that they are somehow not really optimal in many real life Scenarios, independently if we speak about classical waterfall style software development, or about a rather modern agile or scrum method. In the following I just try to summarise a couple of points that I see important based on my experience.

1. Specification: Most software project methodology suppose that there is some kind of a specification for the software; it is relative good specified at waterfall however much more flexible at agile. However in life the first question of the customer if you already have something ready ? The second question is if you have at least something half-ready for prototyping. And the reason for that is that even creating a relative good specification even if it is agile takes time and money. Certainly it can be supported by the business analyst role, so it takes more money and time. As a consequence, custom software development is ususally the last choice for any corporate purchasing process. Customers usually prefer to get something ready or at least-half ready and making modification on that.

2. Architecture: There are a lot of general frameworks that delivers a lot of use-cases out of the box, other frameworks provide self service use-case development even by people without prior development knowledge. In this sense one of the most important step for every software development project is to choose the right software architecture.

3. Agility: Agility can be interpreted only within a certain software architecture. Each architecture can provide several use-cases out of the box or easy to set up, however others are very difficult to implement. One of the biggest problem of each project if the basic architecture should be redesigned during the project.

4. Lean software development: Lean software development can be  interpreted as a way for delivering usable software for the end customer as fast and as efficient as possible. In this sense it makes sense to evaluate if part of the specification or respecification at a new release and the related development can be supported by machine learning algorithms. Certainly the architecture hat to support such an improvement as well, however it is not difficult to imagine that for instance the user interface structure is automaticaly adapted just by analysing the usage of the software itself. There are  initiatives for that for exmape The Grid.

5. Resue - Resell: Most software companies do not want to sell a project only once but several times, even if it is not meant to be develpped as a product for the first run. In this sense one of the most important question for each software project is reuse and resell: How can be the software project sold for several customers, how can be an implemented business-case used in several projects or even on several platforms.   

    

Blockchain for everyone: is it time to have no code application development platforms on blockchain ?

Well, on the one hand, it seems the blockchain technology is starting to get into a hype phase, implying new starts ups with new ideas for each month and a lot of turbulence in media and press. As the technology is however disruptive, meaning creating new markets and destroying old ones, it is pretty difficult to predict what kind of a business models or ideas can be successfully implemented with decentralized ledgers and which do not have the chance. I guess it requires an extensive experimental phase in the next couple of years, implying a lot of small rather proof of concept and prototype projects.

On the other hand, the whole area looks like as the wild west, so finding a professional blockchain developer for each experimental project will be not so easy. First of all everything from a technological point of view is pretty huge, bitcoin, altcoin, ethereum, hyperledger,... and who knows what comes the next week. Secondly, developers who really have got the experience in one field are probably already hundred percent involved in one or more hot start-ups. Thirdly, there is not something like, official developer training or certification for a blockchain developer. As a consequence, it can be predicted that there is gonna be a relative big demand for blockchain developers in the short future that can not really be satisfied. 

A possible solution can be low-code or no-code development platforms on the top of blockchain. No-code or low code platforms provide generally the possibility for IT power or business users to build application pretty fast without having deep coding knowledge. These platforms are usually not Turing complete, meaning not general enough to build up every possible applications, but they provide a way to build a set of typical ones fast and efficient. So, typical proof of concept or experimental blockchain applications can implemented directly by power or business users.

Certainly, the major question is where the focus should be set. One way is to get a general blockchain development platform, like Ethereum, and build a no-code or low-code framework on top. Such a solution would provide the strong integration possibility with the blockchain technology, however integration with other technologies, like mobile apps, storage or data, might be difficult. The other way might be to get a classical low-code development platform, like K2, and extend for a a specific blockhain field, e.g. integrating the services of the bitcoin API. It would provide all the advantages of the existing low-code platform, but it would be rather an interface integration without the decentralized philosophy.

Low-code application delivery in the cloud à la Microsoft

Current trends of Microsoft cloud services show a pretty strong trend of realizing low-code application delivery solutions. As most of these solutions are pretty much in the beta phase it is difficult exactly  to predict how they will look like in a year or two, but it can be easily imagined that a complex low-code application delivery ecosystem will be realized.    

Parts of the ecosystem might be the following:
 - PowerApps for Mobile application building framework.
 - Flow as a  rule engine:  https://flow.microsoft.com/en-us/
 - Office 365 for web publishing and corporate collaboration
 - Office Forms as a Form engine: https://forms.office.com/
 - Azure Machine learning for AI and data mining:
    https://azure.microsoft.com/en-us/services/machine-learning/
 -  ...?

Of course the question is what are a the requirements to be realized for a real enterprise ready low code platform. I think there has to be at least two requirements:
 1. Integration: there has to be a very good integration possibility between both the above mentioned solutions and between other parts of the Azure cloud infrastructure as well. As an example, the same rule of Flow should be possible to use both with a mobile application and with web publishing as well, Similarly general infrastructure elements of Azure, like connecting corporate data with the cloud should be also available (AppFabric, VPN..)
 2. Extensions: If a solutions reaches the architecture limit, there has to be a way to extend the solution with hard-core coding elements, like with Visual Studio and Xamarin for mobile apps,
 and create professional solutions.

Application delivery for such an ecosystem can be realized in two steps:
  a. Low code application delivery: The phase provides the possibility for power users to build up environment on their own or provide the opportunity for partner companies for consulting and training. First step of a whole application delivery, like Proof of concept or prototyping can be realized here as well
  b. Hard core development: real development can be realized if the framework does not provide enough possibility for certain requirements, so further use-cases have to be realized by hard core software development and project management.

Building up consulting and development services based on the technology might contain the following phases:
 i., Beta technology: until the technology is in beta phase, it is not very realistic to make business on the market. However there is the possibility to capitalize the first movers advantage, positioning on the market with strong marketing. As an example, writing blogs, articles, presentations, case studies, or even making indirect partner marketing with the provider (Microsoft).
 ii., Early Phase: at the early phase of the technology it is expected that everything is changing very fast, some integration and extension methods are not carefully designed, as a consequence the whole platform is not very stable. As a consequence rather consulting and training business or rather small development projects are expected.
 iii., Performing Phase: As the platform getting more stable, less innovative and changing slower, full scale extensions and development projects are expected as well. Like classical development projects with off-shoring, project management...

Certainly the major question is if the ecosystem is capable to achieve an enterprise ready and strong performing state or it remains just a couple of innovative island solutions.  

TechReview - Project Siena (aka Microsoft PowerApps in the future)

As one of the major innovation in the direction of mobile development from Microsoft is Microsoft PowerApps, it makes sense to evaluate the possibilities of such a technology (Microsoft PowerApps). Of course the technology is still not 100% on the market, however the framework is based on Project Siena so evaluating that might give an inside to the PowerApp development itself. 

CAN:
 - Windows Apps
 - What you is what you get editor
 - Classical UI elements, Text, Label, ListBox, some limited grid functionality.
 - Datasources, integrating data directly form SharePoint (at the moment some special Datasource for Office 365 is possible), from web search, from classical community sites, like Facebook, yammer, Instagram.    
- Some possibility to locally store data, like importing from Excel.
- Advanced multimedia elements, like video or audio.
- Further developing the project with Visual Studio is possible (with some hacking).
- Sharing and Publishing Applications.

CAN NOT:
- IOS or Android Apps (Theoreticaly it will be possible with PowerApps).
- Implementing
- Implementing complex logic based on the data
- Integrating industrial data sources like SQL, different web services (It is pormised to be extended for PowerApps)

CONCLUSION:

Project Siena is at the moment pretty much in the direction of as a game, build your App, share with your friends, be happy. That is actually a nice thing however it can not be really used for industrial purposes. If the platform will really be extended in a way that it is really cross-platform (having IoS and Android), it supports easy integration of professional data sources like databases or webservices and other industrial systems than it can be used as a real enterprise system. It is still pretty much questionable how much is considered that the system can be further developed by Visual Studio. At the moment it looks rather that way that it will be an only cloud framework where get the functioanlity out of the bix without too much possibility to extend: Microsoft PowerApps Pricing. If it is a possible scenario to further developing by Enterprise Frameworks, like Xamarin than it can really be a great technology.

Role of the customer knowledge in Software Industry

It is a pretty interesting question how does the whole IT industry look like if we consider the role of the customer knowledge. With other words, let we imagine that we have a customer that wants to order user or buy a certain software solution. One of the most interesting question how much the customer knows about the field or software that is being ordered. The following picture shows the rough conceptual model.

Figure 1. The role of customer knowledge in software industry.

Based on the model, the following typical cases can be distinguished.

Everything in details: If the customer knows everything about the software that is being ordered than the most typical way is to create a custom development with one of the classical software development methodology, like waterfall model, V or W model. The specification can be really 100% defined and documented, typically the development can be carried out by a remote development team as well, giving a good potential for offshoring or near-shoring.

Detailed concept: Most customers do not really have a detailed concept about how the software exactly look like, usually because of the missing experience in requirement analysis and software engineering.This provide a perfect way for agile development, having a strong and common communication with the customer, delivering early prototypes and gaining feedbacks from the customer apart from the pure specification. The typical solutions of the fields are methodologies like scrum or extreme programming.

Rough Concept: If the customer has got only a rough concept which software does she need, than the software delivery has to be much more agile. This can be realized in two ways, on the one hand there are some hyper-agile framework like K2 or Oracle AppBuilder that enables to change the environment pretty fast, having practically daily software delivery. On the other hand some software frameworks provides the possibility for a power user to build up applications on their own, like standard SharePoint or partly with a Nintex extension.

Detailed Business Know-How: If the customer has got a detailed business know-how, however she lacks of the IT or software concept and experience than ready products are the best solutions to be offered. Certainly there might be a possibility to set up a team with a business analyst as well, however in this situation the best idea is always to buy a ready software if there is one. If not, custom agile development with business analyst support can be evaluated as well.

Rough Business Know-How: Well that is a difficult situation. Let we imagine a customer that wants to buy a software but she lacks of the necessary software development skills and experience, hence her business know-how is not perfect either. That means that the customer needs both business consulting and software product or development. The other solution that the customer has to buy software solution which is de-facto best practice on the market, meaning that business best practice is actually hard-coded in the software itself. SAP is a leading to deliver such solutions.

Minimal Business Know-How: Well in this case, the customer needs to have both pretty much business consulting and a software solution as well. In this case, the optimal way if the business consulting analysis precedes the software evaluation and the choosen product is actually based on the pure business consulting. 

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.