Impact Of Scalable Computing On Software Engineering Processes

Of late, scalability has become a key quality characteristic which is demanding increased attention from the developer community. There are many factors for this – including evolution of cloud computing and also due to advances in hardware such as multi-core processes.

Software Engineering processes, if followed true to its spirit, easily accommodate scalability requirement of the software being developed. But the width of the gap between process definition and its practice is left to anyone’s imagination.

So, we need to mind the gap, eh?

In this post I have listed few key elements that deserve an increased attention from software designers and developers for few of the software engineering processes. My intention is to link industry best practices and key concerns to software engineering processes.

If your organisation is using review checklists, perhaps you could consider including appropriate points to check these elements.

Requirements Gathering and Management

• Difficulty in
• visualising requirements from a wide base of subscribers for a SaaS application.
• capturing service management related requirements such as metering, billing etc. due to either inexperience or lack of a strong business process backing it.
• Increased focus is needed in capturing and managing
• Interoperability requirements as in future SaaS applications will increasingly inter-operate with each other. As a result, APIs that need to be used and exposed to other products must be known at this stage.
• Security, Privacy, Trust requirements
• User interface requirements as cloud application are likely to be accessed from a variety of mobile devices.
• Need to separate requirements into two groups – common features available for all SaaS tenants and potential customisations

Software Design

• Good assumptions to keep in mind include:
• Design must be akin to that of SOA elements – that is – loosely coupled service components
• The applications must work in a clustered environment
• Database server on the cloud is virtualised and is more susceptible to failure than the physical counterpart.
• You have to design the application for performance which is likely to be bound by SLAs with commercial and/or legal consequences.
• Underlying infrastructure in which your application will run will be of lower quality and lower bandwidth.
• In almost all cases, you have to design your application to be remotely managed in real time.
• Stateless architecture is preferred. In this architecture you are not getting rid of the state data, but you will be either keeping it on a peer buddy server or on the network but never on the server serving your application.
• You have to consciously design
• Security and privacy provisions. You need to be aware of not only standard SSL but also OpenID (Open source solution for unique username and password), PCI DSS (Payment Card Industry Data Security Standards) etc.
• Scalability – including providing inputs for capacity planning, dynamic scalability, load balancing –these factors could be manually controlled or automatic.
• To design for scalability, you must use new modelling methods such as Cube based models.
• Be aware of new protocols, standards and when to use them. For example:
• XMPP – Extensible Messaging and Presence Protocol – which is a way communication protocol between the client and the web server designed to eliminate polling/pinging the host.
• JSON – JavaScript Object Notation – which is a low resource consuming alternative to XML when sending/receiving data using JavaScript
• REST (Representational State Transfer) versus SOAP (Simple Object Access Protocol)
• You should be aware of open source tools available which you can make use of.

Coding

• Be ready to learn or re-learn
• new programming languages such as APEX or Python.
• They could be new to you not necessarily to the IT industry.
• distributed transaction management
• new models for state management
• multi-threading
• Your aim should be to develop lean code that uses as fewer resources (mainly memory and CPU) as possible.
• It is safe to assume that bad performance of the code will ultimately lead to a commercial impact on your company’s services.
• Forget stored procedures! They aren’t easily portable across databases.
• You are likely to use a development infrastructure provided by a “Platform as a Service” provider or an “Infrastructure as a Service” provider. Hence your development practices and review methods are likely to be influenced by these provider’s facilities and practices.
• In order to achieve scalability, you must split your application threads in real time based on functionality and demand.

Testing

• You need to test your applications in an environment similar to a commercial cloud in which you will not have visibility or control. This is likely to be a challenge. You are likely to outsource this to a “Testing as a Service” provider.
• Troubleshooting on the cloud is not easy.
• You should be in a position to test and certify application performance.

Release

• You need re-design your deployment processes in light of virtualised servers.
• You may have to optimise your releases minimising impact on a large number of user community.

Change Management

• If you are developing a SaaS application, expect a part of your software subscribers to come back to you with change requests to your software. Compared to traditional software development, implementing change requests in a cloud environment is not easy. You might want to keep your basic software offering stable yet you will be compelled to honour variety of change requests submitted by your tenants.

Of course it is only a partial list of impact on processes. I will update this post when I collect few more relevant points.

I appreciate your feedback on this post.

SaaS: Software or Service?

No, it is not about definitions. I know it might sound like a dull question to ask especially when everyone knows that SaaS is a healthy combination of both software and service. But my question is given the current conditions, where should the business focus more on – the software aspect or the service aspect?

Paraphrasing – again, the question is would you seek the most powerful, feature-rich software or a reliable, available, fast, economic service? What a question! Answer is obvious. You want both. Aha! That’s where the problem is.

Whenever you fuse two things/concepts/ideas, you will find cases where one of the components dominating over the other. The case having a fine balance of all fused components takes time to evolve or might even be a compromise of all components.

Let’s look at Software part of SaaS: Potential problems include:

• There are hundreds of SaaS applications. But many offer basic, common features which are likely to meet the needs of large subscriber base. Some ecosystems such as SalesForce allow customisation. But not all do so.
• Many SaaS applications are available in two modes – as onsite licensed software and as a SaaS version. In many cases latter is not as effective/powerful as the former. For example: Google Apps.
• This leads to a further problem: the SaaS provider continuously enhances his product leading to change management/end user experience concerns.
• Not all types of software are suitable for SaaS. For example: graphic intensive applications, business intelligence software etc. are not ideal candidates for SaaS as they demand resources.
• Not all SaaS applications are well designed for scalability. This leads to service issues such as latency, availability, performance etc.
• Not all SaaS applications are built for inter-operability. As a result, you could be facing data portability issues, duplicating effort, subscribing to multiple applications etc.

Now let’s look at Service part of SaaS: Potential problems include:

• The term “service” is subject to interpretation. Many SaaS vendors meet the minimum expected services including: availability (or uptime), metering, billing, basic security (again in a variety of ways) and scalability in some form for example: number of users.
• This means, you will be depending on other service providers to get other parts of the service such as storage, archiving, customised security and so on. As the number of parties involved increases, responsibilities need to be clarified, support could be limited and normally issues surface at the border where two service providers meet.
• A good “Software” provider is not necessarily a good “Service” provider. This is because of focus on core competencies. Software houses focus on, well, software engineering and development activities. Over the years, it is likely that their corporate culture including sales, marketing and customer service is tuned towards “license buying customers” – who are likely to be few in number – compared to “rent paying subscribers” – who are likely to be large in number.
• Not all software providers will be willing to take on the service provisioning role as it might blur their business focus. They are likely to outsource it to third parties leading to service complexities.

So what should you do? Be aware of issues at both ends of SaaS, get into details, set expectations and negotiate maximising your advantage.

That’s common business sense, isn’t it?

Cloud Homework: Checklist For Successful Migration into the Cloud

Having heard so much about cloud computing, I am sure that many businesses would like to taste the cloud for real, even as a pilot project. Where do they start? Is there a “checklist” to follow? There could be many, but I haven’t seen a comprehensive one. Perhaps they are hidden behind many other articles or unpublished or not given much publicity they deserve or I need to read more. Anyways, I thought of writing one.

I don’t want to build a “management checklist” for getting onto the cloud. You know, the typical one which says “Set goals – identify parameters – build a decision tree consider risks, pros and cons – taken an informed decision”. But, I want to build a checklist for a business which has already taken a management decision to go for cloud computing or try cloud computing in a small way.

Don’t forget to perform risk analysis after each step to determine whether you are falling into a danger zone. Also at every step, you must identify a business process to cover failure at that step.

1. Set Expectations Right: Success or failure of your journey depends on your initial expectations. Few examples of expectation setting are shown below:
1. There could be performance trade-offs and latency issues.
2. IT Managers will have to give up some control on their IT applications and data.
3. Manager’s ability to forecast IT usage cost is proportional to their ability to forecast IT usage in terms of bandwidth, storage use and CPU cycles.
2. Cleanup Internal IT: “Cleaning up your internal IT is the first step” says Gartner. The term “cleanup” could mean different things to different companies. Some possibilities are explored below:
1. It could mean knowing your IT architecture, making a list of applications in “real” use, development work going on (authorised and unauthorised), nature of applications (mission-critical, critical, support applications)
2. Trying horizontal integration or “pooling” of similar applications and IT services across departments, cost centres, geographical regions.
3. Identifying dependencies between applications and minimising them as much as possible.
4. Grouping applications that need similar hardware, platform or software environment.
3. Cleanup Data: In this step you need assess the state of your data and condition it for movement into the cloud.
1. Prepare to send the data into the cloud in several iterations/increments/waves.
2. Package the data in such a way that it is independent of underlying applications or data environments. This not only helps data management but also switching data service providers when needed.
3. Ensure consistency in definition of data elements
4. Identify different types of data: data under regulation, vulnerable data, private data and so on.
5. Ensure strong metadata descriptions. This helps data archiving, retrieval and estimating impact of data loss.
4. Attempt Virtualisation: Virtualise as much as possible. Move applications that require similar processing environments to the same server.  Example: Exchange and Mail services. Also ensure that business critical applications are served by a pool of servers, just in case of server failure.

Remember following important points about virtualisation

1. Not all servers, services are ideal for virtualisation
2. You cannot and should not Virtualise everything
3. Virtualisation creates single point of failure!
4. Security challenges remain the same after virtualisation
5. Licenses typically apply to physical servers not virtual ones. So paperwork needs to be checked

5. Distribute Right: Decide what to put where. It is unlikely that a single cloud set-up or a cloud service provider will meet all of your requirements. Hence you will have to live with multiple clouds of different types. Follow a general rule of thumb to decide what application goes where. Here are few suggestions
1. Business Critical Application - Don’t take them anywhere, they stay put
2. Internal Development Environment, if any - Private Cloud
3. Shared Services - Shared Data Grid Services
4. Internet based search – Public Cloud
5. Mail, Collaboration – Consider massively scalable services
6. Consider Readymade Solutions First: Look at existing solutions in the cloud. Is there anything that you can pick up right away that meets your needs? For example
1. Storage for new projects from an IaaS provider?
2. Development environment for new products from a PaaS provider?
3. Do any of the SaaS applications meet an outstanding need of the organisation?
7. Choose your cloud service provider: You need to work with multiple partners to realise your cloud dream. You could use several methods to choose your vendors and partners. Few are examined below.
1. Look at companies that provide technology and associated services.
2. Choose companies based on their experience and maturity. It’s a no brainer. But do remember that there could be new entrants who are more agile and innovative than old biggies.

Remember the following while choosing vendors:

a.    You need to consider yourself to be a team captain in this multi-vendor-partner game of clouds. You need to drive agreements, commitments and own the results.

b.    Some vendors may quote compliance with cloud standards. But cloud standards are still emerging.

c.    Don’t dismiss vendors who were earlier seen as System Integrators, just because system integration for/on the cloud is still nascent. They could help you cleanup your internal IT.

8. Cleanup Processes: Cloud solution needs to be built around your business process not vice versa. Hence reviewing your business processes is quite important.
1. Set up a command protocol or governance model clearly identifying who instructs the cloud service provider and who’ll control service parameters.
2. Review or define new processes that govern commercial aspects of the IT. For example: How does your accounting system need to change in order to recognise value of IT assets?
3. Agree with your cloud service provider, an unambiguous method to track key service characteristics such as availability, performance, security, latency, usage and billing.
9. Clearly Communicate: Concerned stakeholders must be informed and educated. Review this checklist with them and modify it based on their feedback. Be prepared to face resistance, fear and confusion as many stakeholders do not yet understand the cloud.
10. Prepare To-Be image of your IT: If you consolidating all of your cloud homework, you should be in a position to draw post-cloud-migration view of your business/enterprise. If you cannot do so, perhaps it is a good idea to repeat these steps as you may not be ready for the cloud migration yet. If you are able to visualise the post-cloud conditions, then you are ready to test the waters.

It is likely that you will reap some benefits from this checklist even if you decide not to migrate to the cloud. Potential benefits include cleaned up internal IT, data and processes.

And don’t forget to share your experience within the industry.