Monthly Archives: December 2014

Digital Build vs. Buy

This entry is part 1 of 1 in the series Digital Build vs. Buy

A common question that I have helped banks struggle with over the years is “build vs. buy”.  For digital banking channels, banks are wondering if they should build a bespoke banking multi/omni/channel offing or buy a packaged product/platform.

The arguments for both sides are compelling:

  • Building a bespoke solution offers the hope of creating a sustainable competitive advantage through a leading software development capability and innovative user experiences that are difficult for competitors to rapidly duplicate.
  • Acquiring a packaged product (or leveraging a platform) allows the bank to benefit from a product road-map and offers the hope of a minimal cost market-parity guarantee.  Minimal cost because product vendors amortize the cost of developing new features over many banks.  All the bank must do is install new versions of the product.

The former is important for differentiating and the latter is important for reducing the cost of maintaining “hygiene factor” features that keep competitors from poaching customers with better channels.

The largest banks can afford to build commodity features themselves although this is in theory a waste of money.  I say “in theory” because it can be tricky to build bespoke differentiating features AND acquire commodity features from a vendor.  This ability must be engineered into the channels architecture somehow.  You need to be able to do one or both of the following:

  • Plug vendor features into a bespoke solution (plug-able components).  The development of which can be facilitated by industry standards and platforms.
  • Plug bespoke features into a vendor solution or platform (extension points).  The development of which are facilitated by the vendor solution/platform’s extensible architecture.

Complicating the digital channels architecture further is the notion of infrastructure.  See my series on strategic technologies.  This is generally a “buy” no-brainer.  No banks should be building their own infrastructure unless they have spotted a technology white space and a way to create a competitive advantage by filling it. Vendors are watching for this, I warn.  At least I am.  I see this as an opportunity to build a new product to sell or platform to run in the cloud.  You see banks attempting to manage this to their advantage by incubating start-ups.  The idea is to get to market first with something that is differentiating, maximize the duration of competitive advantage, and then spin it off once it becomes a commodity to spread the cost of maintaining the technology and keeping its features at market parity.

This is an area of interest for me and you can imagine that I have a lot more to say about it, which is why I am starting this series.

 

Strategic Technology: Service Virtualization (GreenHat)

This entry is part 30 of 33 in the series Strategic Technologies

Service Virtualization encompasses a strategy and tool set for stubbing out components that provide services required to run a component under test.  An example service virtualization tool is IBM’s Rational Test Virtualization Server (formerly GreenHat).

Strategic Technology: Release Coordination (UrbanCode Release)

This entry is part 29 of 33 in the series Strategic Technologies

Software development teams following an agile process to incrementally develop, build, deploy and release enterprise applications quickly find that keeping track of all of the components and inter-dependencies becomes unmanageable.  Spreadsheets become laborious to maintain and do not track the process and keep a record of who did what.

Release Coordination solutions such as UrbanCode Release help control and track incremental releases of complex enterprise applications.

Strategic Technology: Application Deployment Automation (UrbanCode Deploy)

This entry is part 28 of 33 in the series Strategic Technologies

Continuous Integration and other modern code development practices seek to manage scale and complexity, and increase speed and quality, by introducing automation across the software development life cycle (SDLC).  This is especially true of areas that occur frequently and contain many repetitive steps such as the deployment and release processes.

Development teams tend to build and deploy the code for one or more components to a development test server frequently as part of an agile development process in order to find code integration problems early and make sure they have a clear understanding of the status of a project.  However, this can be a laborious and tedious process, screaming for automation.

Additionally, the complexity of releasing enterprise applications to production requires that the release process be well-tested beforehand, and increasingly development teams are finding that the best time to start this testing is during development and early testing efforts.  This requires that the development team use the same process and tools during development that the operations team will use in production.

Application Deployment Automation solutions, such as Urban Code Deploy, facilitate the process of deploying components to servers and releasing them into production.  Urban Code Deploy controls the process, versions deployment artifacts, keeps a record of who deployed what to where, and facilitates incremental deployments.

Mobile Adoption and Trust

Mobile adoption is important to the banks that I have been speaking with.  With the investment that goes into the deployment of a mobile banking or mobile payments solution, reputations are on the line.  The importance of trust in the entire value chain is amazing to me.

Ground zero for where trust affects everything is the trust that individual consumers have in mobile applications–especially with regard to security.

As I contemplate adoption, my own security concerns come to mind.  I use mobile banking when I am in the USA.  As I travel around the world I frequently decide not to access mobile banking because of my lack of confidence in the security of the system.  I wait until I can get my laptop connected, fire up my VPN, type in my one-time-password (OTP) — and only then access online banking.

It is not enough to make mobile systems trustworthy.  We need to be able to explain how they work to users in a way that inspires their confidence.  For me, this is a necessary prerequisite to adoption.

Deeply understanding the concept of trust is important to both of these objectives.  So that is what I am thinking and reading about nowadays.