Fernando Machado Píriz's Blog

Posts about digital transformation, enterprise architecture and related topics

Archive for the ‘Architecture’ Category

Digital Transformation Foundation: “Software Defined Everything” and “Everybody Codes”

leave a comment »

There seems to be an agreement on digital transformation being less about technology and more about business design and a customer centric culture. Obviously it’s not about digital technology: DVDs, as its own name implies, are digital movie containers as opposed to analog videotapes or photochemical films, but wasn’t until Netflix added video on demand via the Internet to the DVDs physical delivery business, that they became a reference on digital transformation.

As George Westerman et al. put clearly in this book -or in this article summary-, it’s the transformational management intensity, i.e. how much top managers are betting on digital transformation, what separates digiratis -digital literates- from the crowds. Nevertheless, companies still need to think on the foundation for their digital transformation, and precisely there is where digital platforms come into place; of the other way around, a digital platform won’t make your company to digitally transform, but can’t transform without one.

What’s that platform? It’s whatever makes frictionless to combine incumbents and partners into your business and for you to participate in others businesses “to execute [your organization’s] digital business strategy”, accordingly to Gartner.

A while ago hardware machines were a physical thing; now we have hardware virtualization by software and then we have virtual machines. Also a while ago we had physical arrays of spinning hard disk drives, and now we have software defined storage; we had physically connected cables, routers, switches, firewalls, etc. and now we have software defined networks; and the list goes on up to big things like software defined datacenters or down to small things like software defined chips, or more precisely field-programmable gate arrays.

Even the IoT devices very common in many digitally transforming businesses can change their behaviors based on the software they run; the dumbest the device, the longer their battery life, less their capability of running sophisticated software or even to run software at all; but put for example a field gateway behind it, connect it to the cloud, and then you have your software defined IoT too.

These platforms have another interesting characteristic: in order to achieve the agility and easiness of adaptation, they embrace change and make changing easier. The [business] rules that control the behavior of the applications running on these platforms can be changed in a declarative way -as opposed to imperative or algorithmic-, eventually through a graphical use interface managed by some business user, not a programmer. It’s declarative, but it’s still giving orders to a computer to do thing, so it’s still programming or coding.

The end user who does acceptance testing doesn’t necessarily use the application itself anymore to see if it works as expected. They won’t do that fast enough and won’t do it as much times as it takes to deliver changes on a daily basis -or even more frequently-. Then the only way is to ask them to declaratively specify how to do the tests instead of doing the testing by themselves. Once again, it’s declarative, but it’s still coding.

So we have end users coding, either by adapting applications running on platforms to do new or different things or by make sure the applications work as they want, we have also more people coding: operators.

Operators now do write scripts to do repetitive tasks. It’s faster, and most importantly, it’s less error pone: once scripts works, they don’t forget steps or make mistakes as human operators sometimes do if they’re tired or in a hurry, stressed by a deadline.

And programmers have always coded; so now everybody codes.

So that’s for me what a platform implies for digital transformation: “software defined everything” and “everybody codes”. And again, this won’t make your organization to digitally transform, but it’s very unlikely that you can transform without one. I’m fortunate enough to have a computer science and software development background; it’s easier for me to understand and to explain to my customers this foundation for digital transformation.

Written by fernandomachadopiriz

December 30, 2016 at 5:14 pm

Every company is a software company, and every software company might to be a service provider

leave a comment »

Software is pervasive. Except perhaps for the one-man (or women) burrito-like shops in the streets, every business runs on software. And they are an exception if and only if they do not accept credit card payments or use online grocery delivery services to refill their raw materials stock. Every company is a software company at the end of the day, either a software-consumer only or a software-development-and-consumer combo.

For those enterprises that do in-house software development and then use that software to run their business, even if it is just a portion of the total software being used, the traditional software development lifecycle might not be appropriate in some circumstances, as we will see in a minute.

An for those enterprises who’s business is to develop software for other enterprises or individuals to consume, the traditional software development lifecycle might not be appropriate either.

By traditional software development lifecycle I do mean the process that creates a software product at the end. I do not care if it is waterfall or is agile, the only thing that matters me is that a software product is created as a result of that process. It has the following characteristics:

  • Many features. Differentiation of the product is based on having as many features as possible for as wide an audience as possible. Products are rarely targeted to specific roles or customer needs.
  • Mean time to failure. As with traditional manufactured products, its main focus is mean-time-to-failure: products are better if they have few failures.
  • Slow update peace. Software product updates are relatively uncommon; it may be through patches for fixing bugs, through service packs to add new functionality, or through entire new versions. And development time for software products is usually large, followed by a maintenance warranty, and then a rest period before starting over.
  • Unknown consumption habits. Once products are released, is hard to know how they’re consumed by users, and take decisions based on usage patterns.
  • On time, on budget. Most important priority is to release products on time and on budget.

In addition, as with traditional manufactured products, reliability is perceived from the perspective of each individual unit. Providing reliability requires controlling quality within the production process. When users experience product problems, they are usually willing to wait until office hours for their problem to be addressed. A problem rarely impacts more than one person at a time. And usually it’s clear for users when problems are due to issues in the software product, as opposed to issues in the environment in which the software runs.

But any of these businesses might be affected by today’s transformation on software demands:

  • Your company develops an mobile software application, it can be a line-of-business application in the enterprises world, or it can be another specific-purpose software application in the marketplace for the consumers world. In the second case, most of these applications at least do store some data or do some kind of processing in a remote back-end, which puts them in the same group as those in the first case: mobile applications that consumes remote services.
  • Your company does electronic business with other companies, it can be exposing internal processes through software where others can participate, or use software applications to exchange information in order to complete a transaction. One way or another you are either providing software based services, or consuming them; probably both.

Did you notice the word software at the beginning of the two previous sentences and the word service at the end? It is not casual –I wrote it that way- but that is what we are and will be seeing in the foreseeable future: mobile software applications that consumes some kind of remote service and software based services exposed for others to consume.

If you feel that any of the two before mentioned categories do apply to your company, either if you are creating software for your own business consumption or in the business of developing software for others to use, and you are still developing software as products, guest what? You are not developing software, you are providing services. I do call these software-based service providers. And that is a completely different beast, want to know why? Let us see:

  • Reliability and agility over features. Differentiation of the service is based on highly reliable capabilities that fit a specific set of market needs. Effective services emphasizes reliability and agility over features.
  • Mean time to resolution. As with traditional utility services, its focus is mean-time-to-recovery: failures will happen, so services are better because of its fast recovery.
  • Continuous updates, continuous development. Software updates are continuous; they might release new features or entire new versions very frequently, and fix bugs on a daily basis. Software development for services is usually continuous; they might have release cycles, but usually those cycles are very short.
  • Detailed usage patterns. Usually it’s possible to collect very accurate and huge amounts of usage data, driving more meaningful decisions.
  • Up and running at appropriate costs. Most important priority is to have the service up and running, keeping the appropriate operating cost.

Furthermore, as with traditional utility services, reliability is a function of the entire system. Providing reliability requires real time, proactive monitoring of the behavior of every system component. When users suffer service outages, the impact is much wider, with one problem impacting a wide array of customers. Response cannot wait for office hours. Product support has to be ready 24x7x365. Users don’t care where the issues are when service outages occur. They might be in the software the service is based on, or in the datacenter, or in the network, or in any of the dependent components

You cannot keep pace with change requests and do not have enough agility to accompany businesses transformations? You have conflicting requirements from different business units or different users groups? You cannot find a good way to organize your software development and software operations teams? Guess what, your software factory is probably not organized as a service provider needs to be organized.

Software factories are organized around software products while service providers are organized around services. And you still wonder why it did not work?

Organizing teams around products means two things. One: you have a team by product, some members can be shared among teams, but teams do work for a product. And two: you very probably have segregation of tasks inside teams: business analyst, architects, designers, developers, testers, and operators if you do run your own software. Does one product use others? Of course, except if you have monolithic giant piece of software, in which case you are way worst that the rest of us, and have more urgent and important problems to solve. Each of the roles of a product team I mentioned before, does work for their own product. They really do not care about products using theirs products and certainly they do not control the other products they consume. And the transition from development to operations looks like developers throwing something over a fence to operators to catch… who cares what happens in the other side? There is always a revenge, operators can always fill bug fix request to developers.

Organizing teams around services, means that a service team has everything it needs to deliver the service and fulfill the service level agreement. There is no fence. Service owner, business analysts, developers, testers and operators sits together upfront to define how the service itself, and the service development process, will look like, end-to-end. Radical, isn’t it? Yes, but that is what you need: An operator telling a software developer what kind of automated deployment, monitoring and telemetry capacities he will need in order to operate the service. These are non-functional requirements and architects and software developers are used to deal with them. A tester telling a software development the way he or she should design the software for him or her to being able to effective and efficiently testing it. These are non-functional requirements too. A software architect or developer telling the service owner what can or cannot be built given time and budget restrictions. Sounds crazy, but these examples are just business requirements, the service owner should be used to deal with them during service definition.

If you think that services are just on the outer layer in contact with the outside world, you are plain wrong. The very same concept can be used in inner layers, in what I love to call the service-oriented enterprise architecture. It is not the same as the plain old service oriented architecture, where application services was the cornerstone. I am talking about business services, application services, and infrastructure services, all organized in the same way, relying one on each other via well defined operation level agreements from the service consumer side, and service level agreements as part of clear service definition from the service provider side.

Biggest software companies (well, it depends on your definition of big) are in fact software-based service providers (Microsoft, Google, Amazon, Facebook, Twitter, Whatsup, Apple, and so on). Your company might not be as big as those, but if it is a software-based service provider, you might have more things in common with them that you think. Someway or another all of them do organize behind the services they do provide. Why you do not?

Written by fernandomachadopiriz

November 20, 2014 at 2:30 am