Mobile Technology

Android Vs iOS Vs Windows Phone 7 Vs Symbian ^3

There was a time when buying a smartphone was easy. You had a couple of platforms and a handful of models to choose from. Things have changed a lot today. You now have over half a dozen platforms out there with hundreds of different models between them, priced very close to each other. It doesn’t help matters when several phones are identical to each other but simply running a different brand of operating system.

You can decide what features you want in your phone but what about the operating system? There is no way you can choose between them looking at the spec sheet alone. Being in a position where we get to use all the latest smartphones on all the different platforms, we think we have answers to your operating system related questions.

What follows is a brief comparison of the top four smartphone platforms – iOS, Android, Windows Phone 7 and Symbian ^3 – where we try to find which one is the best, ultimately narrowing down your number of options while buying and helping you choose better.


iOS is the oldest of the four platforms here. Even though it is four-and-a-half-years old now and has barely undergone any major UI makeover, it still looks great. The UI design has a sense of timelessness to it and no matter how many times you look at it it does not look boring. Apple has also designed it in a manner where it is out of your way most of the time so that you can concentrate on your applications. This means there are no unnecessary animations and transition effects and whatever little is there looks natural and is functional.

Android on the other hand has gone through considerable changes since its first iteration and has only got better with age. Having said that, over the years it has lost some of its simplicity and picked up some UI design elements that seem overdone, such as the 3D image gallery or the live wallpapers, which serve no functional value whatsoever and just consume resources for meaningless eye candy. This behavior is at odds with the usual Google way of designing things, where functionality takes precedents over attractiveness. Still, overall it is an attractive OS and although it lacks the timeless beauty of the iOS or the contemporary look of Windows Phone 7, it manages to look pretty good. Too bad you rarely get to see the real Android below the custom skins.

Symbian ^3 borrows the basic UI design of its predecessor and improves upon it. Despite that the end result is not something that one would call modern. You can see the roots of the operating systems, such as the soft keys at the bottom of the screen that were necessary for devices with buttons and a scroll bar for when there was no kinetic scrolling. It does not look bad per se, but it is not in the same league as others. Luckily, it is skinnable, so you can give a new look to it with a custom skin, although don’t expect to make a swan out of a goose.

The latest entrant into the world of smartphones, Windows Phone 7 took the world by surprise when it was first announced, partly because no one expected Microsoft to come up with something that was so fresh and modern. The beauty of the UI design on Windows Phone 7 is unlike anything that you have seen before on other smartphones.

Unlike other operating systems here, especially Android, which borrowed heavily from iOS initially for their UI design, Microsoft came up with something that was completely original and yet incredibly good looking. So good is the UI design that most people would be seduced into buying a Windows Phone 7 device based on the look itself.

Ease of use

Designing a good looking interface is one thing. Designing a good looking interface that is also easy to use is another and no one does this better than Apple. If you don’t believe us just search online for videos where kids are given an iPad or an iPhone and within minutes they manage to figure out the basics.

In our experience iOS has turned out to be the easiest mobile operating system, where everything was so clear and obvious that anyone who used it for the first time, regardless of age, could figure it out without having to refer to a manual. The reason for this is that it does not assume that the user knows how to use it and because of that you can go around doing basic things without any help. It is incredibly intuitive and makes you wonder why others haven’t figured out a way to make their software work this way. It feels as if it was designed with regular human beings in mind, not robots or geeks. We loved the keyboard especially.

Next in line of intuitiveness is Android. It does not have the same level of simplicity as iOS, were you can detach you brain and still manage to work the interface, but it is still very easy nonetheless. Unfortunately, you would rarely get to use stock Android on every phone you use, which means if you are someone who’s not a geek and are used to, say, an HTC Android phone, you will be lost when you pick up a Samsung Android phone.

So even though Google and the OEMs try to make the UI user friendly, the fact that there are so many different types of them is bound to leave a layperson confused.

Using the early versions of Symbian S60 5th Edition was as much fun as amputating your arm with a dull blade. The UI was designed for phones with keypads and Nokia had done little to ensure that it was usable, if not a pleasure. That’s not the case with Symbian ^3, however, which feels miles ahead in terms of usability.

Things now work the way they should and there is no longer a doubt in your mind whether clicking something will just highlight it or launch it. We still don’t like the way the applications are scattered across the menu and the on-screen keyboard could have been better. But overall the latest version of Symbian is pretty user friendly, and unlike Android, you don’t have to worry about different interface layouts on different devices.

Windows Phone 7 may look great but it isn’t the best when it comes to user friendliness. There are some things that aren’t immediately apparent, such as the way you have to press and hold on certain items to display additional options. Then there is also the quirky behavior of the search button or the tiny call/end keys and the need to unlock the screen before you can receive a call. But more than anything, it’s the lack of basic features such as multitasking and copy-paste for text that really makes things difficult for the users. We do love the keyboard though, which is on par with the keyboard on Gingerbread and almost as good as the one on iOS.


Features was never a strong point of iOS, but over the years Apple has added a lot of functionality to the OS, such as the ability to install applications, multitasking, copy-paste, folders, etc. iOS today leaves very little room for complaint. However, there are some things that Apple is yet to take care of such as Bluetooth file transfers, file manager, mass storage, homescreen widgets and FM radio to name a few, but we have a feeling none of these will ever be addressed.

Fortunately, Apple does add additional functionality with every major firmware upgrade but more often than not these are limited to newer devices, whereas the older ones get the short end of the stick.

Android’s biggest advantage over iOS has been the features and with the latest release Android has almost every feature that you could want, whether it is multitasking, widgets, tethering, Wi-Fi hotspot or Adobe Flash support. It feels the most complete out of all the four platforms here in terms of features, and if features are all that you are looking for then you would be happiest with Android.

When it comes to features, Symbian ^3 is no slouch either. You will find almost every feature here that you get on Android, along with some that you don’t, such as FM radio and USB On-the-Go connectivity. You even get multiple homescreens (three, to be exact) and widgets for them, which are very handy. Features like multi-tasking and copy paste, something others have just discovered and others are yet to, have always been part of Symbian since the first iteration several years ago and have been executed perfectly. Symbian ^3 has most of the features that you would want and there wasn’t anything that we felt it should have that it didn’t.

This is one aspect where Windows Phone 7 fails miserably. For an operating system launching in 2010, Microsoft has left out some pretty major things. Although they are saying they will eventually incorporate most of them through updates we feel they should have had them from day one. While it was excusable to leave out on those things back in 2007, Microsoft has no such excuse, considering they were in the smartphone business even before Windows Phone 7. It does have some good features, such as the homescreen tiles, Xbox Live support, Zune pass and Office integration, but we don’t think that will be enough to compete against the rivals.


When iOS first came out, it wowed the world with its fluid interface that ran perfectly even on the modest hardware of the first generation iPhone. Over the years the OS has become heavier and the proof of this is the way the iPhone 3G struggles with iOS 4.0. But try the same OS on an iPhone 4 and you will notice a world of difference. The UI is silky smooth throughout with no noticeable sluggishness. Even when switching between multiple applications, the UI maintains its smoothness without faltering.

Something similar has been observed in case of Android. As long as you provide it with fast hardware, it runs fine but tends to choke on slower devices. However, unlike iOS, even when running on faster hardware, Android is never perfectly smooth. At times you will notice unexpected and inexplicable slowdowns while going through the UI, which deters from the overall experience. Google has also added unnecessary eye candy to the UI, which also tends to bog down devices with less than perfect hardware.

Also, Android does not use the GPU to render the on-screen images, which means the CPU is overburdened, causing further slowdowns. Still, with some optimization, Android can be made to work pretty well on slower devices.
One of the greatest strengths of Symbian is that it has always been a very light operating system that could be run even by weaker hardware. This is why all the Symbian phones have hardware that seem less impressive than what we are used to seeing on high-end devices, but that is absolutely fine as even on that hardware the OS runs perfectly well.

Since the OS is so light, it removes the need to unnecessarily jack up the hardware and burn more battery in the process. This is why Symbian phones have the best battery life among smartphones. Nokia has also made good use of the on-board GPU to render all the on-screen images, leaving the CPU free to handle other tasks.
When it comes to UI smoothness, Windows Phone 7 is unbeatable. That’s mostly because it is always sitting on powerful hardware, but also because the OS is well optimized for it. This is another good example of the kind of performance you get when you know what the weakest device your software would work on and then optimize it accordingly.

This is also why Android does not work well on low-end devices. The UI of Windows Phone 7 is so smooth, it gives you the illusion of moving physical objects around instead of UI elements, an illusion that Android fails to maintain, thanks to the occasional stutter. Unfortunately, the smoothness is only limited to the default applications as third-party applications could not live up to the same standards that Microsoft has set. We have seen Android developers come up with smoother applications even though they had no idea what phone their application would be running on. We hope things get better in future as these applications are updated.


This is one area where iOS pulls out a massive lead ahead of all the other platforms here. Being around the longest has certainly benefitted it and there are millions of applications available on the App Store right now waiting to be downloaded. Granted that more than half of them are not worth a second look but there are some really brilliant apps here. In fact, the general quality of applications available is the highest among all the smartphone platforms. Some of these apps have truly revolutionized the way we use our smartphones and in a way that not even Apple would have imagined when they made the iPhone. If apps are all you care about more than the device, then iOS is the platform to be on right now.

Although Android is fast catching up with iOS in terms of number of applications, we have failed to come across truly compelling apps that would sway us in favor of the Droid. Most of the great apps on Android are already available on iOS and the remaining ones are Google’s own apps. There are very few great apps or games that are exclusive to Android right now. Sure, things would change down the line and once everyone realizes that Android is the better platform to develop for, considering there are no strict restrictions to follow unlike on the App Store, people would eventually make a move towards Android.

With Android already outselling iPhones in the US soon everyone would want to develop for the OS with the most number of users. Right now though, things aren’t that great as such and if it’s apps you want you should be looking at iOS, not Android. Also, remember that even if tomorrow Android Market does get all the great applications that does not mean they will stop making them for iOS.

There was a time when people boasted about the number of applications that Symbian has. Although it does have one of the best libraries of applications available in terms of sheer numbers, a lack of application store meant it was difficult to have access to them. Now that Nokia has the Ovi Store, things are looking better. When we reviewed the N8 we remarked about the number of applications available for it.

Even though the platform was quite new, the store had decent number of apps available for it. Even now it is growing at a steady pace. But the thing about the Ovi Store is that it will just take care of the basics and you won’t be spoilt for choice as on iOS or Android. Want a Twitter client, there is Gravity. Want an IM app, use Nimbuzz. While this does make it easier to choose, at times you wish you had more apps from the same category to choose from.
Windows Phone 7 has the least impressive library of applications available for it and although one can blame this on the short period of time it has been out we must say the Windows Marketplace didn’t flood with great apps the way we expected it to be.

Just like Ovi, it has all the basic applications covered, but there is nothing here that isn’t available on the other platforms as of now. Also, the applications and especially games seemed unreasonably expensive on the Marketplace compared to App Store or Android Market. The same app as on these stores would cost two to three times more on the Marketplace for no reason.

Perhaps developers are seeing Windows Phone 7 as a premium platform, considering all the Windows Phone 7 devices are high-end and think they can get away with pricing their apps high (the same reason why Android developers either choose to go the ad-based way or through OEMs because they know Android buyers aren’t big spenders).


You probably expected Symbian to be at the bottom of the chart when you started reading this article, but as surprising as it may be, it isn’t. That (dis)honor goes to Windows Phone 7, which has a long way to go before it can play with the big boys. Sure it has the potential to be great with a killer interface that would seduce people into buying this phone (and flame me in the comments section for writing bad about it). But right now there are few reasons to consider buying a Windows Phone 7 handset. Perhaps by the time you are ready to buy your next smartphone, it would be ready for you.

Symbian has gone through a lot of changes over the past years and it has never been in a better shape before. But we feel it has reached the end of its potential and it’s about time it hands over the torch to MeeGo, which will take over as the premium operating system on Nokia’s smartphones. While there is nothing bad about it, others just seem a generation ahead and although it still has the one of the best feature list around it’s not enough in today’s world. The fact the Ovi Store isn’t exactly brimming with great quality apps is also another reason why it lags behind.

iOS has had a long and successful journey and it still has a long way to go, but it seems too rigid in today’s world. The interface design is still top notch and Apple’s attention to detail is exemplary. However, you still miss some of those features, such as widgets for the homescreen or a notification system that does not annoy you. More than anything else, iOS’s biggest trump card is the App Store, which is undoubtedly the best in the business. But the fact that you can only enjoy this wonderful OS on two smartphones, both of which are high-end devices, does not bode well for those who don’t have ‘Ambani’ as their last name.

Android today is a completely different animal compared to what it was two years ago. It felt rudimentary, to say the least, and although it showed potential it was difficult to predict back then what it would be today. Google has worked hard on the OS and thanks to a steady stream of updates it has completely transformed into this new OS that can go head-to-head with the best of the business. It’s still far from perfect though and certain issues such as fragmentation would never be solved. But people have accepted them and found ways to make things work regardless of presence.

Today’s Android offers the best combination of features, performance and support from the developer community in terms of application and the fact that it can run on even a sub Rs. 7,000 handset proves that you don’t need big bucks to own a smartphone. And it’s because of all these qualities that it manages to narrowly nudge ahead of iOS, which has so far been the undisputed king of the smartphone segment. So our verdict is simple, if you don’t have the cash to spend on an iPhone 4, get an Android.

Mobile Technology

Is Android the Future of Mobile Computing?

Devices like Apple’s iPhone and the various versions of Blackberry smartphones are revolutionizing computing. Phones and phone-like devices are increasingly blurring the lines between notebook computers, netbooks and phones. The mobile computing revolution is on!

One platform, however, truly stands out as a potential game changer. That platform is the Android platform from Google. Is Android the future of mobile computing? There is certainly a strong potential for Android to shape the future of mobile computing.

Android’s strength comes from its openness. The Android SDK is open source and the license governing Android itself allows any handset manufacturer to use and modify it. This allows Android to shape the future of mobile computing by making it available to any hardware manufacturer that wants to use it. This means that Android is likely to be the OS of choice for future mobile computing hardware like tablet PCs or e-book readers.

Android’s openness also applies to the selection of mobile carrier. This is one area where many users have been unhappy with Apple’s iPhone. Android is widely available which means that most wireless carriers have an Android handset available. Customers want choice. By giving them choice, Android positions itself as the future of mobile computing.

Android’s greatest strength, however, is its development kit. In the history of computing, the platforms that supported the application developers best became the clear winners. Failure to support application developers with robust tools killed the really Apple platform and IBM’s OS2. This is a mistake that Apple seems to be willing to repeat with the iPhone. The iPhone development tools are difficult to use and the application approval process seems terribly subjective at times. This makes iPhone application development unprofitable for many developers. In contrast, the Android development tools use Java and even C/C++. This allows developers to write applications for Android using languages they already know and use. Additionally, it allows them to use the tools they are already using such as Eclipse. The Android SDK also provides a very robust emulator so that application developers can test their Android applications without relying on physical hardware to do so. The future of mobile computing will largely be determined by the availability of the applications that end users want and need. In this regard, Android is a clear winner.

The biggest danger to Android’s dominance over the future of mobile computing is fragmentation. The ability of hardware vendors to extend Android without contributing their changes back to the Android project could lead to various incompatible versions of Android. To some extent, this has already happened as developers have had to struggle some to make their applications to support different hardware capabilities. This fragmentation of Android would make it harder for application developers to write code for Android. Since the support of application developers is crucial to the success of any computing platform, fragmentation could be a serious threat to Android as the future of mobile computing.

Is Android the future of mobile computing? I think the answer is that it certainly could be. Android’s open nature makes it possible for hardware developers to use it for whatever new devices they can imagine. Its SDK makes it easy for application developers to create the applications users want and need. Both factors make Android a strong contender for the shape of the future of mobile computing. However, there is a danger that hardware vendors will customize Android to the extent that the platform becomes fragmented. If this happens, it will be harder for application developers to write for Android and this could endanger its lead position as the future of mobile computing.

Software Services, Supply Chain Management

The Management Components of SCM

The SCM components are the third element of the four-square circulation framework. The level of integration and management of a business process link is a function of the number and level, ranging from low to high, of components added to the link. Consequently, adding more management components or increasing the level of each component can increase the level of integration of the business process link. The literature on business process reengineering, buyer-supplier relationships and SCM suggests various possible components that must receive managerial attention when managing supply relationships. Lambert and Cooper identified the following components which are:

  1. Planning and control
  2. Work structure
  3. Organization structure
  4. Product flow facility structure
  5. Information flow facility structure
  6. Management methods
  7. Power and leadership structure
  8. Risk and reward structure
  9. Culture and attitude

However, a more careful examination of the existing literature will lead us to a more comprehensive structure of what should be the key critical supply chain components, the “branches” of the previous identified supply chain business processes, that is, what kind of relationship the components may have that are related with suppliers and customers accordingly. Bowersox and Closs states that the emphasis on cooperation represents the synergism leading to the highest level of joint achievement. A primary level channel participant is a business that is willing to participate in the inventory ownership responsibility or assume other aspects of financial risk, thus including primary level components.  A secondary level participant, is a business that participates in channel relationships by performing essential services for primary participants, thus including secondary level components, which are in support of primary participants. Third level channel participants and components that will support the primary level channel participants, and which are the fundamental branches of the secondary level components, may also be included.

Consequently, Lambert and Cooper’s framework of supply chain components does not lead us to the conclusion about what are the primary or secondary (specialized) level supply chain components. That is, what supply chain components should be viewed as primary or secondary, how these components should be structured in order to have a more comprehensive supply chain structure, and to examine the supply chain as an integrative one.

Baziotopoulos reviewed the literature to identify supply chain components. Based on this study, Baziotopoulos suggests the following supply chain components:

  1. For customer service management: Includes the primary level component of customer relationship management, and secondary level components such as benchmarking and order fulfillment.
  2. For product development and commercialization: Includes the primary level component of Product Data Management (PDM), and secondary level components such as market share, customer satisfaction, profit margins, and returns to stakeholders.
  3. For physical distribution, manufacturing support and procurement: Includes the primary level component of enterprise resource planning (ERP), with secondary level components such as warehouse management, material management, manufacturing planning, personnel management, and postponement (order management).
  4. For performance measurement: Includes the primary level component of logistics performance measurement, which is correlated with the information flow facility structure within the organization. Secondary level components may include four types of measurement such as: variation, direction, decision and policy measurements. More specifically, in accordance with these secondary level components, total cost analysis (TCA), customer profitability analysis (CPA), and asset management could be concerned as well.
  5. For outsourcing: Includes the primary level component of management methods, and the strategic objectives for particular initiatives in key areas of information technology, operations, manufacturing capabilities, and logistics (secondary level components).
Software Services, Supply Chain Management

Supply Chain Business Process Integration

Successful SCM requires a change from managing individual functions to integrating activities into key supply chain processes. An example scenario: the purchasing department places orders as requirements become appropriate. Marketing, responding to customer demand, communicates with several distributors and retailers, and attempts to satisfy this demand. Shared information between supply chain partners can only be fully leveraged through process integration.

Supply chain business process integration involves collaborative work between buyers and suppliers, joint product development, common systems and shared information. According to Lambert and Cooper operating an integrated supply chain requires continuous information flows, which in turn assist to achieve the best product flows. However, in many companies, management has reached the conclusion that optimizing the product flows cannot be accomplished without implementing a process approach to the business. The key supply chain processes stated by Lambert are:

  • Customer relationship management
  • Customer service management
  • Demand management
  • Order fulfillment
  • Manufacturing flow management
  • Supplier relationship management
  • Product development and commercialization
  • Returns management

Other key critical supply business processes combining these processes stated by Lambert such as:

  1. Customer service management
  2. Procurement
  3. Product development and commercialization
  4. Manufacturing flow management/support
  5. Physical distribution
  6. Outsourcing/partnerships
  7. Performance measurement

1. Customer service management process:

Service Management is integrated into Supply Chain Management as the joint between the actual sales and the customer. The aim of high performance Service Management is to optimize the service-intensive supply chains, which are usually more complex than the typical finished-goods supply chain. Most service-intensive supply chains require larger inventories and tighter integration with field service and third parties. They also must accommodate inconsistent and uncertain demand by establishing more advanced information and product flows. Moreover, all processes must be coordinated across numerous service locations with large numbers of parts and multiple levels in the supply chain.

Customer Relationship Management concerns the relationship between the organization and its customers.Customer service provides the source of customer information. It also provides the customer with real-time information on promising dates and product availability through interfaces with the company’s production and distribution operations. Successful organizations use following steps to build customer relationships:

  • Determine mutually satisfying goals between organization and customers
  • Establish and maintain customer rapport
  • Produce positive feelings in the organization and the customers

2. Procurement process:

Strategic plans are developed with suppliers to support the manufacturing flow management process and development of new products. In firms where operations extend globally, sourcing should be managed on a global basis. The desired outcome is a win-win relationship, where both parties benefit, and reduction times in the design cycle and product development are achieved. Also, the purchasing function develops rapid communication systems, such as electronic data interchange (EDI) and Internet linkages to transfer possible requirements more rapidly. Activities related to obtaining products and materials from outside suppliers requires performing resource planning, supply sourcing, negotiation, order placement, inbound transportation, storage, handling and quality assurance, many of which include the responsibility to coordinate with suppliers in scheduling, supply continuity, hedging, and research into new sources or programmes.

3. Product development and commercialization:

Here, customers and suppliers must be united into the product development process, thus to reduce time to market. As product life cycles shorten, the appropriate products must be developed and successfully launched in ever shorter time-schedules to remain competitive. According to Lambert and Cooper, managers of the product development and commercialization process must:

  • Coordinate with customer relationship management to identify customer-articulated needs;
  • Select materials and suppliers in conjunction with procurement, and
  • Develop production technology in manufacturing flow to manufacture and integrate into the best supply chain flow for the product/market combination.


4. Manufacturing flow management process

The manufacturing process is produced and supplies products to the distribution channels based on past forecasts. Manufacturing processes must be flexible to respond to market changes, and must accommodate mass customization. Orders are processes operating on a just-in-time (JIT) basis in minimum lot sizes. Also, changes in the manufacturing flow process lead to shorter cycle times, meaning improved responsiveness and efficiency of demand to customers. Activities related to planning, scheduling and supporting manufacturing operations, such as work-in-process storage, handling, transportation, and time phasing of components, inventory at manufacturing sites and maximum flexibility in the coordination of geographic and final assemblies postponement of physical distribution operations.

5. Physical distribution

This concerns movement of a finished product/service to customers. In physical distribution, the customer is the final destination of a marketing channel, and the availability of the product/service is a vital part of each channel participant’s marketing effort. It is also through the physical distribution process that the time and space of customer service become an integral part of marketing, thus it links a marketing channel with its customers (e.g. links manufacturers, wholesalers, retailers).

6. Outsourcing/partnerships

This is not just outsourcing the procurement of materials and components, but also outsourcing of services that traditionally have been provided in-house. The logic of this trend is that the company will increasingly focus on those activities in the value chain where it has a distinctive advantage and everything else it will outsource. This movement has been particularly evident in logistics where the provision of transport, warehousing and inventory control is increasingly subcontracted to specialists or logistics partners. Also, to manage and control this network of partners and suppliers requires a blend of both central and local involvement. Hence, strategic decisions need to be taken centrally with the monitoring and control of supplier performance and day-to-day liaison with logistics partners being best managed at a local level.

7. Performance measurement

Experts found a strong relationship from the largest arcs of supplier and customer integration to market share and profitability. By taking advantage of supplier capabilities and emphasizing a long-term supply chain perspective in customer relationships can be both correlated with firm performance. As logistics competency becomes a more critical factor in creating and maintaining competitive advantage, logistics measurement becomes increasingly important because the difference between profitable and unprofitable operations becomes more narrow. A.T. Kearney Consultants noted that firms engaging in comprehensive performance measurement realized improvements in overall productivity. According to experts internal measures are generally collected and analyzed by the firm including

  • Cost
  • Customer Service
  • Productivity measures
  • Asset measurement, and
  • Quality

External performance measurement is examined through customer perception measures and “best practice” benchmarking, and includes

  • Customer perception measurement, and
  • Best practice benchmarking
Software Services, Supply Chain Management

Supply Chain Management

Supply Chain Management (SCM) is the process of planning, implementing and controlling the operations of the supply chain as efficiently as possible. Supply Chain Management spans all movement and storage of raw materials, work-in-process inventory, and finished goods from point-of-origin to point-of-consumption.

Supply Chain Management encompasses the planning and management of all activities involved in sourcing, procurement, conversion, and logistics management activities. Importantly, it also includes coordination and collaboration with channel partners, which can be suppliers, intermediaries, third-party service providers, and customers. In essence, Supply Chain Management integrates supply and demand management within and across companies. More recently, the loosely coupled, self-organizing network of businesses that cooperates to provide product and service offerings has been called the Extended Enterprise.

Some experts distinguish Supply Chain Management and logistics, while others consider the terms to be interchangeable. Supply Chain Management can also refer to Supply chain management software which are tools or modules used in executing supply chain transactions, managing supplier relationships and controlling associated business processes. Supply chain event management (abbreviated as SCEM) is a consideration of all possible occurring events and factors that can cause a disruption in a supply chain. With SCEM possible scenarios can be created and solutions can be planned.

A supply chain is a network of facilities and distribution options that performs the functions of procurement of materials, transformation of these materials into intermediate and finished products, and the distribution of these finished products to customers. Supply chains exist in both service and manufacturing organizations, although the complexity of the chain may vary greatly from industry to industry and firm to firm.

Supply chain management is typically viewed to lie between fully vertically integrated firms, where the entire material flow is owned by a single firm and those where each channel member operates independently. Therefore coordination between the various players in the chain is key in its effective management. Cooper and Ellram compare supply chain management to a well-balanced and well-practiced relay team. Such a team is more competitive when each player knows how to be positioned for the hand-off. The relationships are the strongest between players who directly pass the baton, but the entire team needs to make a coordinated effort to win the race.


Supply chain management must address the following problems:

  • Distribution Network Configuration: Number, location and network missions of suppliers, production facilities, distribution centers, warehouses, cross-docks and customers.
  • Distribution Strategy: Including questions of operating control (centralized, decentralized or shared); delivery scheme (e.g., direct shipment, pool point shipping, Cross docking, DSD (direct store delivery), closed loop shipping); mode of transportation (e.g., motor carrier, including truckload, LTL, parcel; railroad; intermodal, including TOFC and COFC; ocean freight; airfreight); replenishment strategy (e.g., pull, push or hybrid); and transportation control (e.g., owner-operated, private carrier, common carrier, contract carrier, or 3PL).
  • Information: Integration of and other processes through the supply chain to share valuable information, including demand signals, forecasts, inventory, transportation, and potential collaboration etc.
  • Inventory Management: Quantity and location of inventory including raw materials, work-in-process and finished goods.
  • Cash-Flow: Arranging the payment terms and the methodologies for exchanging funds across entities within the supply chain.
  • Supply chain execution is managing and coordinating the movement of materials, information and funds across the supply chain. The flow is bi-directional.


Supply chain management is a cross-functional approach to managing the movement of raw materials into an organization, certain aspects of the internal processing of materials into finished goods, and then the movement of finished goods out of the organization toward the end-consumer. As organizations strive to focus on core competencies and becoming more flexible, they have reduced their ownership of raw materials sources and distribution channels. These functions are increasingly being outsourced to other entities that can perform the activities better or more cost effectively. The effect is to increase the number of organizations involved in satisfying customer demand, while reducing management control of daily logistics operations. Less control and more supply chain partners led to the creation of supply chain management concepts. The purpose of supply chain management is to improve trust and collaboration among supply chain partners, thus improving inventory visibility and improving inventory velocity.

Several models have been proposed for understanding the activities required to manage material movements across organizational and functional boundaries. SCOR is a supply chain management model promoted by the Supply Chain Management Council. Another model is the SCM Model proposed by the Global Supply Chain Forum (GSCF). Supply chain activities can be grouped into strategic, tactical, and operational levels of activities.


  • Strategic network optimization, including the number, location, and size of warehouses, distribution centers and facilities.
  • Strategic partnership with suppliers, distributors, and customers, creating communication channels for critical information and operational improvements such as cross docking, direct shipping, and third-party logistics.
  • Product design coordination, so that new and existing products can be optimally integrated into the supply chain, load management
  • Information Technology infrastructure, to support supply chain operations.
  • Where-to-make and what-to-make-or-buy decisions
  • Aligning overall organizational strategy with supply strategy.


  • Sourcing contracts and other purchasing decisions.
  • Production decisions, including contracting, locations, scheduling, and planning process definition.
  • Inventory decisions, including quantity, location, and quality of inventory.
  • Transportation strategy, including frequency, routes, and contracting.
  • Benchmarking of all operations against competitors and implementation of best practices throughout the enterprise.
  • Milestone payments


  • Daily production and distribution planning, including all nodes in the supply chain.
  • Production scheduling for each manufacturing facility in the supply chain (minute by minute).
  • Demand planning and forecasting, coordinating the demand forecast of all customers and sharing the forecast with all suppliers.
  • Sourcing planning, including current inventory and forecast demand, in collaboration with all suppliers.
  • Inbound operations, including transportation from suppliers and receiving inventory.
  • Production operations, including the consumption of materials and flow of finished goods.
  • Outbound operations, including all fulfillment activities and transportation to customers.
  • Order promising, accounting for all constraints in the supply chain, including all suppliers, manufacturing facilities, distribution centers, and other customers.
Rich Internet Applications

Reasons to Love Flex

Flex was designed in order to give Flash Developers an edge when developing Rich Internet Applications (RIAs). Although RIAs can be built from within Flash, there are various limitations, especially when it comes to a developer’s time.
One of the major reasons why Flex is becoming more and more popular is because it utilizes ActionScript 3.0. One important thing to note is that the Flex environment does not use a Timeline. This does not mean that it is limited. Rather, Flex has been developed more for programmers and less for designers.

Let’s take a look at the reasons to love to develop RIAs (Rich Internet Applications) in Flex.

  1. Flash is everywhere — The Adobe Flash 9 Player has about 98% market penetration across browsers. This means that when you launch an application on the Web, you are virtually guaranteed that anyone will be able to use it. Compared to the distribution statistics of other RIA runtimes, there is simply no contest.
    Flash is cross-OS, or “platform-agnostic”: it runs in Windows, Mac and Linux. It is also installed in every type of browser, making it the only RIA technology that can truly claim to be a “write once, run everywhere” platform.
  2. Flex = Flash on steroids — Flex is Flash and Flash is ActionScript 3.0 (or more specifically, Flex runs on the Flash Player, and the Flash Player’s language is ActionScript 3.0.)
    In ActionScript 3.0 you have all the aspects of a mature, robust programming language: strong runtime typing, class inheritance, interfaces, error handling, a built-in event model, sealed classes, method closures, custom namespace accessors, regular expressions, E4X. The Flash Player incorporates the Tamarin ActionScript 3.0 Virtual Machine with the power of a Just in Time (JIT) compiler, which interprets SWF application bytecode into machine-level instructions so that your code runs as fast as the processor can handle. Warp speed, Scotty!
    And since Flex is built on top of Flash, you have the full power of the Flash APIs to draw in real time with lines, gradients and fills and manipulate and animate vectors, bitmap data, and visual assets, complete with matrix transformations, programmatic Photoshop-like filters, and blends. Flash allows communication using a dizzying array of data formats, but if you don’t find the format that suits your needs, create your own using a binary socket and custom interpreter! You also get high-definition, full-screen, hardware-accelerated video capabilities, supported by enterprise-capable video encoding and streaming server products.
    Flex 3 adds another layer of power onto the Flash runtime: a visual markup language called MXML, and a full-featured compiler that includes compiler metadata and data binding. The Flex framework adds class libraries for natively managing HTTP requests, RPC services, and Web Services, a dizzying array of visual UI components, a deep linking framework for browser integration, an API for AIR applications that can interact natively with the desktop, logging and unit testing frameworks, and much much more, all of which will be covered in this book. Not to mention an IDE based on Eclipse, and a whole suite of server tools for your application to communicate with the backend using native ActionScript class objects.
  3. Flex is open source — The Flex Software Development Kit (SDK), which comprises the compiler, the component framework, and several other tools, is a free, open-source development platform. Although Flex Builder is neither free nor open source, it is built upon Eclipse, and can be installed standalone (with Eclipse built in) or as an Eclipse plug-in alongside other Eclipse development environments. In fact, Adobe Flex Builder has been voted Best Open Source Developer Tool for RIAs by InfoWorld’s Best of Open Source Software Awards.
  4. Interoperability — ActionScript 3 has XML baked into it as a native format with E4X parsing capability, facilitating JSON and XML data transfer. The Flash Player is able to interface directly with JavaScript in the browser through a native JavaScript communications API, and is able to recognize SWF filename query name-value pairs. Two great examples of Flash-AJAX interoperability are Google Finance and Yahoo! Maps Canada, both of which combine the versatility of an enhanced hypertext application with the interactive power of the Flash runtime.
    The Flash Player also includes XML and binary sockets capability, including traditional GET and POST HTTP requests.
    The Flash Player natively supports image file formats GIF, JPG, PNG, media file formats MP3, FLV, F4P, F4A, and F4V, including the AAC, MP4, M4V, M4A, 3GP, and MOV multimedia container formats, encoded in Sorenson Spark, On2VP6, H.264, MPEG-4, MP3, or AAC.
    The Flash Platform also enables some unique RIA communications protocols. Connected to the Flash Media Server, the Flash Player is also able to stream video and audio using the RTMP protocol, and its rights-encrypted cousin RTMPE, as well as the new RTMFP format in Flash 10. Using the Adobe AMF protocol, the Flash Player is able to communicate complex ActionScript objects directly with data services applications on the server. Adobe LiveCycle Data Services and its open-source cousin BlazeDS enable bidirectional ActionScript-to-Java object transfer, and the ColdFusion server allows for ActionScript-to-CFC object transfer. Third-party data service implementations such as WebOrb, AMFphp, and Zend enable native ActionScript object communication with the.NET and PHP server languages. Other third-party data services solutions exist for languages such as Ruby and Python.
    The Flex framework contains APIs that allow very easy deployment for HTTP requests, Web Services, and RPC services data transfers. So needless to say, a Flex application can communicate a wide variety of web technologies, allowing for a plethora of server integration options with an impressive array of interoperability with many data formats, languages, and protocols.
  5. The community — Conceived with the same spirit as the Flash community, the Flex community is passionate, generous, and vibrant, always coming up with new ways to alert each other of the latest quirks, share their discoveries, their tips, their components, and their experiments, helping Adobe make a better product. And Adobe does an incredible job of feeding that fire: it actually listens to the community, and rewards them with changes to product development that directly reflect what designers and developers has been asking for, going so far as to organize events and surveys that elicit feedback for the sole purpose of making Flash and Flex better and better. One has only to look at all the new features in Flash Player 10 and those planned for Flex 4 to know that Adobe has listened to and cares about its community. Many Flash and Flex designers and developers, including the writers of this book, really enjoy what they do for a living, and thrive on that energy. And this level of passion and commitment to each other and to the evolution of the platform shows through in every Flash and Flex conference, every technical blog, every community forum and list this author has ever visited.
  6. Creative Suite integration — When Adobe purchased Macromedia in 2005, it brought to the Flash and Flex development scene the possibility of the full force of its Creative Suite of applications. As of Creative Suite 3, we can now experience the fruits of that promise, as we now have seamless integration between Flash and Illustrator, Fireworks and After Effects. This opens up a vast sea of creative possibilities for Flex development, enabling even “richer media” applications than ever before. See Chapters 26 and 29, which cover Flash and Flex workflow integration in greater detail.
  7. Flex enables modular, rapid application development (RAD) — Flex natively encourages a Model-View-Controller (MVC) separation of application parts through the use of MXML, which is an XML-based visual layout markup language that facilitates rapid prototyping and development (see Listing 1-1 for details). In the simplest Flex MVC pattern, the View or interface layout is typically coded in CSS and MXML, and the Controller or application logic is typically coded in ActionScript, though one is not constrained to these norms. This will be covered in greater detail in Chapter 60, “MVC Frameworks.” Flex Builder also has a Design View, which allows for the visualization of MXML layouts, and a Properties View, which allows for the setting of inspectable component properties directly in the IDE (see Chapter 5, “Introduction to Flex Builder 3,” for details).
    Flex also enables a variety of modular compilation and deployment methods. You can pre-compile application modules or class libraries to increase compilation efficiency, code distribution, or asset management. By compiling all your fonts into one module, and all your skins into another module, for example, you cut down overall application compilation time and increase asset management efficiency. You can compile SWFs to be compiled in the main application as embedded assets, which can be easier to use than Flex modules, or you can opt to load SWF application subcomponents at runtime, decreasing the initial application filesize.
    The application footprint can also be mitigated by the use of persistent framework caching, where you can compile your application sans the Flex framework, allowing the Flash Player runtime to preload and cache the framework as a separate class library on the client. This means that after the Flex framework has been downloaded once, it is cached on the client, and your application will load much quicker for the user. See Chapter 66, “Modular Application Development,” for details.
  8. Adobe AIR — AIR brings the power of Flash and Flex to a whole other level. With AIR, AJAX applications can be deployed to the desktop, or a Flash/Flex application can be deployed to the desktop, in either the PC, Mac or Linux OSs, with access to system windowing and local file system interactivity. Or even more powerfully, both AJAX and Flash can be leveraged together in the same application, in ways that could never be done in a conventional browser environment. You can apply Flash bitmap filters and tweens directly onto an HTML object, or have a JavaScript object communicate directly with an ActionScript object without the intermediary of a communications format. This enables the development of flexible, “sometimes connected,” desktop solutions that have not previously been possible in the realm of RIAs.
  9. Seeing is believing — But don’t take our word for it. Check out some Flex and AIR applications yourself. Have a look at some of the showcased applications, and you’ll see exactly what we mean:
Pre Sales, Software Services

Proposal Building Process in Presales

Based on the size and/or complexity of the project, the study effort may vary. The typical process steps for conducting a requirement study and proposal building are outlined below. These steps are often being conducted concurrently, iteratively and, in fact, some steps may be omitted entirely, depending on the complexity and criticality of the effort. Process steps include:

  1. Determine requirements for the study
  2. Determine objectives, scope and approach, and plan the effort
  3. Conduct a current state assessment
  4. Identify potential solutions
  5. Determine the feasibility of each option
  6. Document and communicate the results of the requirement study, and obtain approval to estimate development for the recommended solution


1.       Determine Requirements for the Study: Business Problem or Opportunity

Requirement studies are used to determine the approach to solving a business problem or seize a new business opportunity, the approach is slightly different. In the case of a business problem, the Business Analyst first determines and documents the problems faced by the organization and the potential areas of study required to address the issues. The analyst then conducts root cause analysis to determine the full nature of the problem, the actual cause (or causes) of the problem, the adverse impact it is having on the business and the criticality and required timing of the resolution.

To take advantage of a new business opportunity, the analyst defines the opportunity in as much detail as possible to understand the scope and determine the nature of the study. This information is then used to determine the methodology or approach to be undertaken to complete the study. For each business problem and/or opportunity, the analyst drafts a requirements statement describing the business need for a solution.

2.       Determine the Objectives, Scope and Approach and Plan the Study Effort

To plan the requirement study effort, the Pre-Sales/Business Analyst first assembles a team of skilled resources who collaboratively perform the following tasks:

2.1   Establish specific, measurable objectives that the recommended solution must meet. These objectives provide the basis for formulating options for consideration.

2.2   Develop benefit criteria upon which alternative solutions will be evaluated in the form of quantitative measurement criteria by which to judge the success of the investment in the recommended solution.

2.3   Define scope of activities to be performed during the study.

2.4   Define deliverable(s) to be produced from the study; if it does not exist, develop a template for the final proposal document.

3.       Conduct a Current State Assessment

The study team conducts a limited amount of internal analysis when initiating the requirement study. These may include review of business objectives, strategy and vision; analysis of current business processes; and assessment of current (as-is) and future (to be) documentation. The current state assessment consists of a review of all or part of these elements, depending on the nature and scope of the study:

3.1   Strategy – Review the business vision, strategy, goals and measures.

3.2   Business Area – Describe the mission of each line of business or business unit that is a stakeholder for the area under study, and collect relevant organizational charts.

3.3   Locations – Document the physical location of each impacted business unit.

3.4   Data and Information – Identify the major types of business information required. It is also helpful to list the repositories which retain the information listed.

3.5   Infrastructure – List each of the current business technologies impacted by the initiative.

3.6   Processes – List and provide a description of each of the current business processes relevant to this project.

3.7   Competitive Arena – Describe the current business environment within which the business operates, including:

  • Market analysis, competition, products and services available
  • Emerging markets and technologies
  • Regulatory or legislative changes.


4.       Identify Potential Solutions

At this point the study team conducts external research activities to uncover general information about the industry, the competitive environment, best practices, risks and results of the actual similar approaches that have been implemented by others to solve the business problem or seize the new opportunity under consideration. Then, the team identifies as many potential options as possible to meet the objectives identified in the planning process. It is important to note that the list of possible alternatives should include the option of doing nothing.

5.       Determine the Feasibility of each Option

For each potential solution, typical analysis steps include the following:

5.1   Describe the solution option in as much detail as possible, perhaps building a high-level work breakdown structure (WBS), a hierarchical decomposition of the solution, to bring the full scope of the effort into view.

5.2   Identify methods to assess the alternative, ensuring the analysis of the economic, operational and technical feasibility of the option. Examples of methods include: prototyping to prove the highest risk portions of the solution option are technically feasible, market surveys to ensure there is a demand for the solution and it will be economically feasible, technology capability assessment to ensure the solution does not require new, unproven technology, and business staff interviews and IT staff interviews to determine operational feasibility.

5.3   Identify expected results of the assessment.

5.4   Define assessment steps.

5.5   Undertake feasibility analysis for each option.

5.6   Review results to ensure completeness.

6.       Document and Communicate the Results of the Requirement Study

Proposal document would describe the results of the requirement study for each identified alternative solution. Share the proposal document with the executive sponsor of the study, and secure approval to estimate development efforts for the recommended option.

Types of Requirement

The types of requirements that exist vary based on the problem domain and methodology that the Pre-Sales/Business Analyst works with. For the proposal, the following types of standard requirements types have been defined:

  1. Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. This describes such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
  2. User Requirements are statements of the needs of a particular stakeholder or class of stakeholders. This describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
  3. Functional Requirements describe the behavior and information that the solution will manage. This describes capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.
  4. Quality of Service Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. This is also known as non-functional or supplementary requirements.
  5. Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
  6. Implementation requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.


The deliverable from this effort is the scope statement and supporting information defining the following components by inclusion or reference. This proposal documentation is input to determine the development efforts, and includes the following elements.

  1. Summary of activities the led up to the recommended solution including the business environment analysis and competitive analysis.
  2. Strategic alignment describing how the initiative fits with organizational direction or mission.
  3. Business objective(s) and high-level business requirements.
  4. Product description and scope.
  5. Project boundaries including context diagrams to provide a visual model of the scope of the project.
  6. Assumptions and constraints.
  7. Major project milestones, funding requirements and limitations.
  8. Initial project approach including resource requirements, methodology, tools, and training requirements.
  9. Current and future standards, policies, regulations to be adhered to and impacts to the initiative.
  10. Commercial Off-the-Shelf (COTS) packages available vs. customized development of the solution.
  11. Dependencies, including downstream systems, interfaces, supporting data required.
Pre Sales, Software Services

What is proof of concept?

A proof of concept or a proof of principle is realization of a certain method or idea(s) to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory is probably capable of being useful. A proof-of-concept may or may not be complete, and is usually small and incomplete.

In software development, proof of concept (abbreviated PoC) is often incorrectly used to describe three processes with different objectives and different participant roles. These uses of the phrase proof of concept are therefore not synonymous and are delineated below.

  • A proof of concept can refer to a partial solution that involves a relatively small number of users acting in business roles to establish whether the system satisfies some aspect of the requirements.
  • By contrast, the objective of a proof of technology is to determine the solution to some technical problem, such as how two systems might be integrated or that a certain throughput can be achieved with a given configuration. No business users need be involved in a proof of technology.
  • A pilot project refers to an initial roll out of a system into production, targeting a limited scope of the intended final solution. The scope may be limited by the number of users who can access the system, the business processes affected, the business partners involved, or other restrictions as appropriate to the domain. The purpose of a pilot project is to test, often in a production environment, whether the system is working as it was designed while limiting business exposure.

Why we need proof of concept?

A PoC generally should be done early in the development cycle or to sell a software concept. It is used to validate technical feasibility, helps identify potential stumbling blocks, identifies what a platform can or can’t provide, helps determine the scope and level of customization necessary to complete the project.

The PoC can also help identify performance issues.  Generally, today, we assemble many of our applications / solutions in a “composite” fashion.  We’re re-using services, functions, etc. from other applications.  This re-use requires integration points.  It’s these integration points in our overall “context” that we’re vetting with the prototype effort.  While also validating assumptions regarding what the platform or framework can or can’t provide.

The outcome is a technical feasibility confidence factor along with factors that impact overall scope and estimate of effort.

Effective PoC

To create an effective PoC we need to create a PoC project as well as a document which will cover all the technical, functional approach of the project.

Below are the useful tips to create an effective PoC project:

  • Create the same architecture for PoC project which you are going to use for the development.
  • Design a Login page with exciting graphical interface if security is a primary concern for the project.
  • Home page with logo, all the possible menus/tabs, Search, links for the other sub functions of the project.
  • The home page should speak about the entire site what we are going to achieve.
  • If the content of the home page or other pages is based on user Roles then you should develop different pages showing how it will look like after login depending upon Roles.
  • Dashboard if required.
  • One or Two pages/modules which will show that how you are going to design/develop the pages/modules and how they are linked to each other. These page(s) should be the most important parts of the application.
  • If the project has any report(s), create a sample report with exciting look & feel so that the client can understand how you are going to produce the results.
  • If the project has any graph(s), create a sample graph.

In brief, it should cover all the features in short so that one can see what you are going to achieve after in the production version of the project.

 How to create PoC Documentation

The documentation for your PoC should explain about the entire design of the project. You add the below points with brief description.

  • The architecture detail which will be used for development.
  • Add all the technologies, third party tools you are going to use, with explanations why you have chosen the same.
  •  Add all the modules with brief functionality which will be developed.
    • Add the methods how you are going to handle security.
    • Explain each menu you have used in the PoC project.
Methodology, Pre Sales, Software Services

Extreme Programming

Similar to Scrum, XP (Extreme Programming) starts the process by creating a backlog of work to perform during a sprint/iteration. XP creates the backlog by working with customers and creating user stories. In parallel with this work, the team performs an architectural spike, during which they experiment with the features to envision the initial architecture. XP classifies this work as the exploration phase.

The planning phase follows exploration. This phase focuses on identifying the most critical user stories and estimating when they can be implemented. Tasks are defined for each feature, to aid with estimating complexity. The team outlines an overall release schedule, with an understanding that a high level of uncertainty exists until the work begins. A release will have one to many iterations, which are typically 2- to 4- week construction windows.

When an iteration begins, the specific plan for the iteration is revisited. The team adds any new user stories and tasks that have been discovered since the overall release was outlined.

XP integrates customer testing into the development iteration. The customer is asked to identify the acceptance tests, and the team works to automate these tests so they can be run throughout the iteration.

The planning phase is followed by the productionizing phase, during which the code is certified for release. Certified means the code passes all customer tests plus nonfunctional requirements such as load testing, service-level requirements, and response time requirements. You can see an overview of XP in below figure.


Some of the characteristics of XP are as follows:

  • Specific practice —Unlike Scrum, XP is specific about the practices that should be used during a software project. These practices include pair programming, TDD, continuous integration, refactoring, and collective code ownership.
  • Modeling —XP teams frequently use modeling to better understand the tasks and architecture needed to support a user story.
  • Simplicity —Teams perform the minimum work needed to meet requirements.
  • Automation —Unit and functional tests are automated.
  • Quality through testing —Features are tested constantly, and developers check each other’s code via pair programming.

These are some of XP’s strengths:

  • Customer-focused (it’s all about user stories)
  • Quality via frequent testing
  • Constant focus on identifying and delivering the critical user stories
  • High visibility on project status
  • Great support for volatile requirements

It also has weaknesses:

  • Need for team maturity —Practices such as pair programming and TDD require responsible developers, and they aren’t always easy to obtain.
  • Dependency on testing —If developers know that significant testing will take place downstream, they may be less than diligent when they’re creating designs.
  • Scalability —XP may not work well for large projects.
  • Dependency on team member co-location —The team usually has a team room.

XP supports many of the critical goals of an agile process, such as dealing with volatile requirements and delivering prioritized, working software as soon as possible. XP also supports the principle of just enough, keeping with the lean philosophy of minimizing waste.

XP has sometimes been criticized for its lack of formality in system documentation and system design. In recent years this has changed, and XP teams now create the documentation needed to support a project’s customers.

Pre Sales, Software Services

Creating effective Information Architecture in 11 steps

Information Architecture (also known as IA) is the foundation for great Web design. It is the blueprint of the site upon which all other aspects are built – form, function, metaphor, navigation and interface, interaction, and visual design. Initiating the IA process is the first thing you should do when designing a site. Clients sometimes view the development of an IA to be impractical, both in terms of the time it takes and the skill needed to do it effectively. But this mentality is slowly changing. A good IA is incredibly effective, and knowing the basics of the IA process can save both time and money in the long run.

The following steps define a process for creating an effective information architectures.

  1. Understand the business/contextual requirements and the proposed content for the system. Read all existing documentation, interview stakeholders and conduct a content inventory.
  2. Conduct cards sorting exercises with a number of representative users.
  3. Evaluate the output of the card sorting exercises. Look for trends in grouping and labeling.
  4. Develop a draft information architecture (i.e. information groupings and hierarchy).
  5. Evaluate the draft information architecture using the card-based classification evaluation technique.
  6. Don’t expect to get the information architecture right first time. Capturing the right terminology and hierarchy may take several iterations.
  7. Document the information architecture in a site map. This is not the final site map, the site map will only be finalised after page layouts have been defined.
  8. Define a number of common user tasks, such as finding out about how to request holiday leave. On paper sketch page layouts to define how the user will step through the site. This technique is known as storyboarding.
  9. Walk other members of the project team through the storyboards and leave them in shared workspaces for comments.
  10. If possible within the constraints of the project, it is good to conduct task-based usability tests on paper prototypes as it provides valuable feedback without going to the expense of creating higher quality designs.
  11. Create detailed page layouts to support key user tasks. Page layouts should be annotated with guidance for visual designers and developers.

Developing an information architecture in this way enables you to design and build a system confident that it will be successful.

It simply isn’t good enough for organizations to build functionality or write content, put it on their computer systems and expect people to be able to find it.

Developing effective information architecture is an essential step in the development of all computer systems.

Effective information architectures enable people to quickly, easily and intuitively find content. This avoids frustration and increases the chance that the user will return to the system the next time they require similar information.

Remember: “People can only appreciate what they can actually find”