Category Archives: Technology

Technology Sustentation 75: Mobile Movement (Madness)

The mobile movement, as we pointed out in technology damnation 75, is as much of a curse as it is a blessing. As we noted in our post:

  • you will be expected to work anywhere, anytime;
  • data entry will be painful as small screens, and smaller keyboards made for real mice, will be the norm (and you can thank Apple and their new mini 4″ iPhone); and
  • task time will triple as small, limited power processors, chug, chug, chug trying to deal with media-heavy websites and bloated data transfer protocols despite the fact that
  • suppliers and customers will expect a whole new level of relationship management

So what can you do?

  • define your relationship management processes and protocols and make sure new suppliers and customers know, day one, what they can expect and the level, and kind, of service you will provide
  • limit the amount of functionality that your applications will support on a mobile device to needed functionality
  • make sure mobile applications and devices support scanning/sensor reading as much as possible (bar codes, QR codes, RFID chips, etc.); manual data entry should be web-based OCR (image, upload for server processing, user override, save); etc.
  • make sure support channels are well defined so that only people who are working or on call get contacted when requests come in — don’t automatically route a non-critical support call to the primary rep at 3 am in the morning when a secondary support rep is on call half a world away at 3 pm in the afternoon (VOIP is a wonderful thing)

We’re stuck with these devices whether we like ’em or not, so let’s make sure we design for them appropriately and work-life boundaries are properly set, otherwise, we’ll all be asking:

Can I Play With Madness?

Technology Sustentation 80: The Cloud

As SI said in our post on technology damnation 80, software was good. Hosted ASP was better. True multi-tenant SaaS was better still. But the “cloud” is, more often than not, the one step back that follows the two-steps forward.

The cloud is not a white fluffy cloud full of day dreams, it is a gathering storm cloud that could soon erupt and flood your entire operation while the hail it dispenses pummels you to a bloody pulp.

As per our damnation post, if you are not careful, you could:

  • lose your mail,
  • lose your data,
  • lose your platform, and
  • lose your customers as well as
  • lose your supply chain visibility,
  • lose your revenue stream, and
  • lose all the cash in your bank account

And you could be permanently lost at sea when the floods carry you away.

Unless, of course, you take precautions. What kind of precautions?

  1. Make sure that your providers’ platforms are designed in such a way that not only is there no data cross-pollination, but that there is no access cross-pollination. This may require that the provider not only create a new instance for each client, but run it on a new virtual machine. (The database can be on one server, as long as it’s encrypted and the encryption for each client uses a unique key so that if a hacker gets through to the database through another client’s poor security configuration, and gets all the data, your data can’t be decrypted.)
  2. Make sure that the provider supports encryption across all of your data, not just parts of it, and that it is up to date (and up to snuff). Even data that might be considered inconsequential can be enough to be damaging if enough bits of it are pieced together.
  3. Make sure the provider does near-real time incremental, replicated, distributed, off-site back-ups to make sure that, in the case of hardware failure (or FBI/NSA server seizure), your data is not lost.
  4. Make sure the provider has multiple real-world data centres that the platform can be run on in case one (or more) data centres become unavailable.
  5. Make sure the provider has a distributed fault-tolerant up-time monitoring solution that can detect if an application instance becomes unavailable and restore the most recent back-up to a different data centre and do the necessary re-routings in (near) real time.

In other words, security, fault-tolerance, and distributed processing and back-up are critical. Without it, you’ll be hacked, your system will go down, and you may not get it (or even your data) back.

Ninety Years Ago Today …

The world lost a great physicist by the name of Heike Kamerlingh Onnes. While this is not a name most people know, he was the first person to liquify helium and to discover superconductivity — both of which are critical to the modern technological age. Liquid helium, which has a temperature of 4K (4 degrees above absolute zero on the Kelvin scale, and 73 degrees below the boiling point of liquid nitrogen which can freeze a banana in as little as 3 minutes) is a key ingredient in superconducting magnets and the primary cryogenic refrigerant.

But more importantly, superconducting is used to make ultra-fast digital circuits, microwave filters for your movie phones, and, most importantly, superconducting magnets (which are the most powerful electromagnets that are required by MRI machines, mass spectrometers, and particle accelerators).

Have We Reached B2B 3.0 Yet? Part 3: B2B 3.0, A Definition

As per Part I, over seven years ago, Sourcing Innovation published Introducing B2B 3.0 and Simplicity for All, which is available as a free download, to help educate you on the next generation of B2B and prepare you for what comes next. The expectation was that, by now, we would be awash in B2B 3.0 (Business to Business 3.0), which was simply defined as the first generation of technology that actually puts business users on the same footing as consumers, but are we?

In Parts I and II we discussed the history of B2B 1.0 and B2B 2.0 in order to conclude that, neither B2B 1.0 and 2.0 was not enough. B2B 1.0 launched the internet era, but proved that connectivity, and even basic functionality, is useless without content (that helped buyers find what they needed and sellers provided what buyers needed) and community (as the right parties need to come together). B2B 2.0 brought the internet era to the mid-sized business, but ultimately proved that creating private networks and marketplaces didn’t add anything because while redundancy in data centres is good, network redundancy is bad and only increases costs, not value.

That’s why we need B2B 3.0 but is it? First we need to discuss B2C 3.0.

B2C 3.0, which was kicked-off by sites like Froogle (Google Product Search), PriceGrabber, and PriceWatch, allowed consumers to search and browse product listings from multiple sites. TechRepublic, CraigsList, and ComputerShopper provided the community for these consumers to discuss providers and products and find what they wanted at the price they wanted. And C2C 3.0 sites like MySpace, FaceBook, and Twitter connect more users than ever before.

B2B 3.0 is the business equivalent. It’s the next generation of B2B that adds content, community, and open-connectivity to B2B platforms. More specifically, open connectivity that is free to all to access, open community that allows all buyers and sellers to come together though dynamically created virtual networks on an open, shared, secure, and decryption-supporting API to conduct business as needed, and the depth of content required to support complex direct purchases. It’s what B2B 2.0 should have been, but without the unnecessary redundancy and the necessary cost.

B2B 3.0 is an open platform enabled by:

  • web services
    like Google Maps that allows supply chains to be plotted
  • intelligent agents
    that can automatically place re-orders and identify market data of interest to the buyer or supplier
  • meta-search
    that works over multiple catalogs, on multiple sites, accessed using multiple EDI, (c)XML, or other standard protocols
  • real-time collaboration
    instant messaging, (visual) VOIP, screen sharing, and collaborative document authoring
  • semantic technology
    that can identify news stories and reports of interest
  • mashups
    to normalize data from hundreds (or thousands) of file and data formats into a common taxonomy
  • analytics
    that can process, and make sense, of all of the information streams and present meaningful information and actionable insight
  • workflow
    as a good process is an effective and efficient process

But are we there yet? To be continued …

Data Breach Response Planning Part II


Today’s guest post is from Torey Guingrich, a Project Manager at Source One Management Services, LLC who specializes in helping global companies drive greater value from their IT and Telecommunications investments.

In our last post, we indicated that no industry or company can escape the potential of a data breach, including yours. Given that large retailers, health insurance companies, financial services firms, and the U.S. federal government have had to deal with reporting and responding to large-scale data breaches in the last few years, it’s becoming more and more of a certainty that if your organization is of a significant size and has a fair amount of valuable (or secret) data, at some point it will be desirable enough for a third party to try and obtain it illegally through a hack or systems breach. And bolstering prevention alone might not be enough, any weakness at all in any system used by your organization, or a supplier, could be enough to let a black-hat in. Thus, the best preparation, and prevention, is often that which assumes a breach will occur and has plans, and relationships (as per our last post), to identify, patch, and deal with the breach as fast as possible. A quick response can be the difference between a breach that is only able to capture a few dozen credit card numbers at one point of sale and a breach that continues to infiltrate the system until thousands of credit card numbers across dozens of points of sale are compromised.

In order to insure a quick identification and response to a data breach, along with choosing partners to work with for a breach, the key to quick action is to have the internal processes and systems in place to respond accordingly. As part of preparation, companies are beginning to define data breach response teams to develop response plans and define clear roles for the key departments that would need to spring into action. Typical roles/areas that companies would need to include are:

  • IT
    Companies look to their IT departments to immediately identify and rectify the point of entry for any breach. IT will need to work with forensic IT partners to get as much information as possible in terms of scope and scale of the breach, as well as ensure systems are up and running to keep regular operations functional.
  • Communications
    The Communications team needs to take a lead role in responding to a breach and developing key materials (e.g. for the call centre scripts, press releases) within a data breach response plan. Appoint a role or individual as the spokesperson for the company and ensure that all employees, and even BOD members, know to reference back to this person when contacted regarding a breach.
  • Operations
    The call centres are one of the first areas that are overloaded when a breach occurs. Work with Communications to prepare scripts and materials to provide to the call centre (both in-house and outsourced) to ensure a consistent message and avoid unwanted confusion. Your Operations team also needs to ensure that internal operations are adjusted as necessary and continue to run given that a breach has occurred.
  • Legal
    Your Legal department (and likely outside counsel) will need to look at the compliance and regulatory implications of a breach. Depending on what industry your company is in, data breaches can carry hefty fines. To report a breach accurately, key individuals will need to work with IT to understand scope and scale and report to the necessary governing bodies. As this landscape evolves, ensure that the Legal department is aware of any new regulation that your industry may become subject to, e.g., proposed cybersecurity regulations for banks and insurers. The Legal team will likely need to engage with law enforcement, either local or federal, and manage the company’s duties along with direction received from law enforcement.
  • Suppliers
    A supplier may in fact be the point of entry for a breach in your system, as has been the case with many of the breaches in recent years. It is important to understand that your customers will still be looking to your company to respond and correct that breach. Because you will need to work with your suppliers to correct and adjust operations as necessary, Procurement should consider including language in contracts or RFXs that obligates suppliers to comply with your response plan in the event of a breach.
  • CEO/C-Suite
    Within each of these groups, it is vital to have individuals within the response team that can make decisions. Typical delegation and “chain of command” decision making will only delay the process and response that your company is able to provide. Executives and team members also need to understand that they may need to make decisions with incomplete information; this can be difficult for organizations who are accustomed to making decisions only when all variables are identified. Due to the scrutiny and reputational risk at stake, it should be made clear to customers that decisions are being made given the information available at the time.
  • Procurement
    Procurement will need to support supplier selection, contracting, engagement, and performance management of all necessary outsourced response services. Procurement will be managing different priorities and requirements from various stakeholders involved in a breach, i.e. all of the departments above, and will be expected to act as a cornerstone in ensuring that different requirements are met and balanced when and where they need to be.

As indicated at the start of this post, in today’s atmosphere, the possibility of a breach cannot be ignored and relying too heavily on breach prevention without a focus on response preparation can be a costly mistake. To avoid this, make sure your organization has a validated response plan and key materials primed in advance of a breach to be able to promptly respond to customers and return to normal operations as quickly as possible. Given the department’s experience in supporting process improvement and collaboration, Procurement is in a unique position to champion a proactive approach to response planning by bringing together stakeholders and identifying strategic partners that can enable the entire organization to respond to the dreaded data breach.

Thanks, Torey.