The Infosys Labs research blog tracks trends in technology with a focus on applied research in Information and Communication Technology (ICT)

« July 2013 | Main | September 2013 »

August 26, 2013

Achieving Consistency and Agility through Design Accelerator

Couple of years back, I was involved in a debate with my friend about a possible design to a particular problem. Even after a lengthy discussion, we were not able to reach a conclusion. We differed on quite a few aspects. His principles were centred on high modularity, while mine was centred on performance and scalability. Another point of contention was between maintainability of code and faster delivery. Now when I look back at that discussion we had, we both were right considering our thought process that led to our own design. This is a typical problem designers face. Since design involves lot of art, it is bound to be more subjective. There isn't anything called "The Best Design". However there are designs that follow the best practices and those that don't. But why shouldn't there be a Best Design to a particular problem. Let us look at some of the reasons.
  1. Design is Dependent on Designers

More often than not, Good design is dependent on good experienced designers. It depends a lot on the individual skills and foresight of the designers. A designer who has had the experience of designing a similar system in the past is more equipped to design the system better. However with the demand for experienced designers growing up, it is a challenge for project teams to always have very experienced designers in their ranks.

  1. No Repeatability in Design

Software Design is inherently filled with subjectivity. That is, it depends a lot on how designers comprehend the requirements and design the system. Two good individuals may design the system in two different ways. Both the system could be well-designed. Moreover, if the same individual is asked to design the system at a later point in time, he /she may design it in a different way. That design may be better/worse than the previous one. In other words, the design lacks repeatability and consistency.

  1. Lack of Documented Reasoning in Design

Imagine a scenario where one of the designer has to leave the project mid-way, the person taking over the project will have to understand why the system was designed the way it was. Despite having the best of tools and models, understanding the thought process behind a design becomes a challenge.

  1. Increased Design Effort , Reviews and Rework

Design goes thru its own process where in the design is first drafted, then reviewed and then sent for rework. Reviewer need to spend lot of effort in reviewing different aspects of the design.

Let us look at how we can counter the issues stated above and reduce the subjectivity that shrouds the design. For this we need to go into the basic principles that drives the Software Design and also the Best practices which every designer follows. One way to approach Design is to think in terms of Components that realize the system. Well-Designed Systems have well-designed components. If we identify these components in a systematic way, then we are in the right path to Design. Following section explains more on this.

Identifying Components

The first step most designers do is to understand the requirements and look for requirements that are related to each other. They might look for certain groups of requirements that perform similar action. In other words, the designers are identifying the components that are needed to build the system. A consistent way of identifying components would help designer to think alike.

Now the key question is how do they identify components and on what basis do they say these groups of requirement correspond to a particular component? There must be something that these requirements share in order to be classified and grouped. In other words, there must be some attributes/traits these requirements possess. Therefore it would be fair to say that these requirements can be clustered based on their attributes

Let us look at some of the attributes on which the requirements can be clustered.

  1. Data Entities

First thing a Designer might look for is Data Entities that are found in the requirement. If two requirements share a data entity, the designer might consider grouping those requirements. For example Opening a Bank Account can be one requirement. Address Verification of the customer can be another requirement. Both the requirements share the data entity Customer Data. The Designer might consider grouping these two requirements.

  1. Adjacent Actions

Requirements specify some action about what a system has to do. When a designer sees a natural flow in actions in the requirements, he might consider grouping them. For example Validation of customer data is logically a next step to Entering data. They can be considered for grouping.

  1. Actor

Another pattern that designers look for is the Actor who is going to use the system. In the above example, filling application form is done by Customer, while Address verification is done by banking officer. Customer and Banking officers are two different actors who are using the system. If the same Actor is being referred in different requirements, then those requirements can be grouped.

From the above points, it is clear that requirements that share the same data entities, same actor and that are adjacent can be grouped (clustered) together. In reality, requirements might share some attributes say data entities and actor or just one of the attributes. It becomes a big challenge for designers to quantify the extent to which requirements share attributes. Moreover, with huge sets of requirements and less time to deliver, going thru the requirements and identifying these clusters manually becomes a big challenge. The process if repeated, has a high chance of different clusters being formed. In other words, it is not a repeatable process.

This is precisely what Design Accelerator intends to address. It automates the identification process. It takes the requirements that are captured in UML tools and identifies the potential components by forming clusters. These clusters can then be imported into Design Tools, from where the designers can start their design process. This way it brings repeatability into Design process. Moreover, it assists Designers to think and reason out in a similar way. More importantly, it saves a lot Designers' valuable time.

Conclusion

By bringing in repeatability and consistency, the design Accelerator enables the Designers to approach the design in a consistent manner. Lot of Design effort can be reduced thereby bringing in more agility into the process. Having said that, Design is a phase which still has lot of subjectivity and automating this phase remains a challenge. We at Infosys Labs are focusing on building solutions to address this space. This blog focused on design taking component approach. In future, we will be covering other aspects and approach to Design. This is just a beginning of a series we have planned.

 

References

  1. T. Kohlborn, A. Korthaus, T. Chan and M. Rosemann, "Identification and Analysis of Business and Software Services;A Consolidated Approach", In IEEE Transactions on Services Computing, 2009,
  2. Towards a Foundation for Quantitative Service Analysis An Approach from Business Process Models , IEEE on Services Computing ,2010

 

August 19, 2013

Mobilization : Required Business Orientation and Associated Technology Options

Mobile computing has become the business transforming factor for many of the enterprises. With the advent of cheaper and affordable smartphones, phablets and tablets getting released every now and then, the mobile market is on the rise and hence the consumption of the services via those mobiles are also on the high leading to the increased demand for the mobilization of consumable services.

Gartner references by saying that more than 60% of the CIOs plans to enhance their organization mobility capability in the next three years and out of them, more than 40% wants them to be seen as industry leader in the mobility adoption. This is the another promising  trend that is double assuring the fact that the organizations have already started looking into mobilization to help increase the consumption and usage of mobility. Given the market fact that the mobility is on the rise , and organizations have been wanting to go mobile, what does it really mean for an organization/enterprise to go mobile? Let's have a look at the  same .

Mobility Strategy  and compelling roadmap along with Orientation towards it are key to an Organization for effective Mobilization:

First and foremost, the organization/enterprise  wanting to go mobile must have a Mobility Roadmap in place, which should have been the outcome of their business analysis lead identification and prioritization of services that needs to be mobilized to reap business benefits in terms of Cost, Increased user base, customer satisfaction, Productivity increase etc., The few critical answers that the Mobility Strategy should be answering includes

  • Departments within the Organization where the Mobility is applicable (with the immediate need and long-term need) along with the Categorization and understanding of each departments Customer segments (B2C, B2B, B2E).
  • This immediate and long-term needs should have primarily categorized by ROI yield and second important being the market demand which could have driven by the Operating market, Customers, Employees etc.,
  • For B2B, the organization should have a clear vision on whether the organistaion will distribute the devices or it wants to support the kind of devices their business partners will bring in (accordingly the roadmap will have an impact)
  • For B2E, the organization should  have a clear vision of whether the organistaion will distribute the devices or it wants its employees to bring them (accordingly the roadmap will have an impact)
  • Within departments , details on Services Identified for Mobilization should have been envisioned categorized by Immediate Term (0-6 months), Mid-term (6-12 months) and Long Term (1-3 years).
  • Organization should have thought of or budgeted for the application development , Deployment Approach ensuring their business Criticality and Security needs that each departmental app must adhere to and should have decided on whether to go for In- house Deployment or Externally Hosted Deployment approach or open to both.

With the answers or clarity to the above being in place , the immediate next step is to move on to putting this strategically designed roadmap in action. There comes the technology to be decided. Lets have a brief look on the options that mobility market poses in front  of the business today:

Technology Options:

In the world of mobility, there are multiple technology options available to choose from namely
   (a) Browser Based Application development Option: This is very similar to the existing and more prevalent Internet option, where the systems are accessible via browsers of Laptop/Desktop, but with associated complexities brought in by mobility like  varying browser capabilities and largely classified screen seizes and aspect ratios, OS Specific navigations and rendering needs to be taken care of addressed. This option will not require any application footprint on the device and hence considered to be relatively easier to manage as all the assets are managed from a single server entity mostly.

Enterprises can go for this option , when the applications in need does not warrant any native capabilities of devices like accessing address book, invoking camera, considerable local storage and the applications can be completely online.

    (b) Native Application development Option: These are the applications developed using the respective OS provided technology stack like Android Java for Android devices, Xcode for IOS etc., These kind of applications will require considerable footprint on the devices and requires professionals with specialized skills specific to platforms/OS to be available. These kind of applications will provide the ability to have access to the native capabilities like invoking camera, harnessing the toucless gesture capabilities. This option requires more amount of work to be done on the each OS side and less work at the server side.

Enterprises can go for this option, when their applications in need requires access to native capabilities, offline/synchronization needs, high performance and presence on the playstore.

    (c) Hybrid Application  Option: This option harnesses the power of both the options discussed above. When a native application internally uses a headless browser and presents that section with the HTML content it is classified under hybrid. The entire application can be designed in this fashion in which case  native app  becomes container to hold the HTML views (in a headless browser concept) and can still have the access to the native capabilities.

Enterprises can go for this option, when their applications in need requires access to native capabilities and are willing to minimize the cost  compared to that of a native with compromise on Performance.

Each of these above discussed options have their own merits and de-merits. It should be purely the business requirements that should drive the technology option to be chosen to meet the business requirements  to be met without any compromise. In my next blog I shall share the insights into the Merits and De-Merits of these technology options and the relevance of MADP vs AD.

August 12, 2013

Choice of Channel for mobile application development and launch

With the rapid growth of mobility channels, developers and enterprises are faced with the challenge and choice of catering to all the channels. However catering to all channels in one go is not the right approach. We explore the ways to select the channel for mobile application development and roll out based on various parameters including the business angle. 

Firstly let us define "channel" in the context of mobile application. Channel can be defined in following (and more) ways


i. Channel can be various technologies available like Android, Black Berry, iOS, Window Phone.
ii. Channel can be the end device on which the application is being run, like a mobile phone, a laptop (yes laptop is a mobile device!), a tablet or a custom built device (tough devices from vendors like Motorola etc.). 
iii. Channel can be defined in the context of type of application like native application, browser based application or even hybrid application.


Whichever way the classification is, one has to give due diligence while selecting the appropriate channel for the mobile application.
Selection of channel can be looked form various angles:


• Enterprise mobility strategy
• Usage  or the type of application
• Market/competition/Industry trends
• Technology (or platform) Eg. Android, iOS, Windows Phone, SMS, USSD, iPTV etc

Let us explore the above one by one.

Enterprise Mobility Strategy: The mobile application is a result or a by-product of enterprise mobility strategy. Hence the first aspect to look for is, to align it with the enterprise mobility strategy. For example, if an enterprise is launching application for its employees and its strategy is to provide handsets as well (which in most cases limited to certain channels), applications should target only those channels.

Usage or type of application: In mobile applications single most important factor (even above the functionality) is the usage by the end user.  Hence this factor must be considered while selecting the channel. Let us consider an example, a CRM mobile application is fairly complex even on a mobile device; and many fields and functionalities are essential even while on the go. Trying to fit this into a smaller device will definitely hit the usability. Instead the application can be targeted for Tablets or bigger screen size phones (Phablets) only.

Market/completion/Industry trends: First two aspects above deal with internal dynamics of the enterprise. Enterprise has to consider the external aspects also. External aspects are influenced by market, competition, industry standards and the technology.  Usually these parameters are of importance in the consumer applications. Consider a bank developing a mobile banking application. It has to consider the market dynamics like what is the market trend in terms of channels (mobile/kiosks/ATMs etc), It has to consider what are the areas its competitors are active in (or not active as the case may be).

Technology (or platforms): This is somewhat related to enterprise strategy for the targeted market of the application. Certain channels are better suited for certain technology. For example Black berry has proven security credentials in the market. So an application that needs higher security BlackBerry is one of the options. Similarly a closed and controlled environment may mean iOS as an option. Also simple applications could go on push notifications or SMS or USSD without the need of complex smartphone applications.

Another dimension for channel selection could be the distribution model for the application. Certain channels like Apple market place(iTunes) have stringent measures for an application to meet to their standards, which may not be possible in all scenarios. Hence those channels may have to be ruled out or other distribution models to be thought of.

Channel selection challenge is generally faced due to the constraint the enterprise has. Constraint may be the resources or the time to market etc. So, optimal approach would be to go in a phased manner, i.e.  Launch the application in one (or few channels) and then expand to other channels. In such scenarios enterprise is faced with the challenge of skill set to launch application in multiple platforms/channels. In such scenarios best option will be to go with the Mobile Application Development Platforms (MADP). Mobile Application Development Platforms help enterprises develop applications in a channel/platform and with minimal effort same can be deployed on other channels/platforms.


CONCLUSION
Selecting a channel for a mobile application is a strategic decision based on various internal/external factors. In the rapidly expanding and dynamic domain this is a trick decision to make and one size suits all approach may not work. Hence one should use the mixed and phased approach for publishing mobile applications across various channels. MADP is the solution one should look forward to when phased approach is used as it would help in reducing the time to market and the application development cost leading to competitive advantage for the enterprise.