Last time, I wrote about the general idea that we are dealing with here: building software today is very different than it used to be just 10 years ago, and we ahre decomposing the software in many ways, creating micro and mini services that depend on the backend execution but also on number of external, customer facing channels that drive customer experience.
We used to have a monolitic design and in those days you wanted to control everything because you HAD to control everything – there was no external software that you can pass part of the functionality of relay on something that would do a job instead of you.
This notion of “control” was particulary important for Government and their “solutions” – there was strong imperative that whatever your build for them (or they build by themselves) needs to be under full control. Infrastructure, applications, processes and data had to be under same “control” as the rest of the “real infrastructure” – not because that was the thing that they needed to do, but because they were only good at this one thing – making things unreachable, silosed and monolitic.
Today’s world is a little bit different, and Government in having a hard time to adapt to the reality of how do we make or expect that software behaves, but mostly collaborates with the rest of the world. The collaboration actually means opening, connecting, trusting other parties, setting up security boundaries… and it is not going to be less complex anyday soon.
What changes do we see here?
Making Application work well with others required at least few significant changes in the design and today we have a new paradigms in place…
- Applications are no longer Monolitic by Desing: one broke the functionality of the application in many smaller pieces, actually driving that componentization down to specific task for a specific role that is running or orchestrating that task, If successful – application in not really an application anymore (application that we Know it), and it becames an “service”, just because you can isolate UX from the “code”.
- Applications are … Services, really: in the new world, most of the functionality of the application is embbeded in the code that is encapsulated into a specific service that have specific interface where you communicate with it. That service exposes it interface to the outer world, not just to the other parts of the application (services) that are internal to the organization, but also to the rest of the external world, given the proper security authorizations to use that service. That way we enable reuse of the service (one to serve them all – one service with specific functionality should serve the rest of the world here).
- There is a glue between Services, Services and Applications, called API: or application programming interface. Back in the old days, we used to look at it as a specific ways to connect applications and that is why this title is misleading: it should be Services Programming Interface or SPI. Today, you actually connect services using it and only occassionaly some applications, but since you dont reuse applications but services… you got my point.
- Since Services represent specific functionality (application) they could also represent a model (of specific application object): modeling software, applications, services toward objects that they represent is a great step forward in software architecture and design. This way, we can define and reuse a specific model (for example, model of the object called road) which is exposed through Services and API so that external world can create new objects of type road that have specific characteristics defined by the model. Now, it sounds complicated, but it really straightforward – you use model so that you can have some order and structure (and many more things, but for now, that is more than enough).
pic: software defined applications
Why is this important for the Government?
Well, not just for the Government, it applies to any industry, but since we are going to dive later on into Government architectures, lets map those bullets to the Government benefits:
- It is all about creating Services not Applications. Today, Governments are still looking into buying Applications or Software or Solutions…. they should actually buy Services. Services of the high level (like, buying Services from outsources to perform specific task) but also buying Services at lower level (like, buying Service that maps the roadblocks). Key element here is Services Management – when you create, procure, manage Services you should do that in controlled environments – for example Shared Services Center (more on that in next posts). That way you can enable universal access to all other apps and services that need them to perform their own taks and Services.
- It is all about opening Services to Internal and External World. That way, you enable true value of Services – scalability and reuse. For that, you need to create Service Catalog (again, under some controlled environment like Shared Services Center) and make sure that others can use them. And of course, you need to be sure that you are not breaking any already existing “contract” that external world have with your service, but that is Services Management 101. You can actually do this without SSC but then you need to manage multiple endpoints and you are very dependant on other entities – this is example that we have in many Governments today where one ministry or Agency is controlling specific data service or app service.
- There is universal Government API and it is called Government Service Bus.Creating multiple endpoints that connect to others endpoints are usually the best way to have a mess – that is precisely why we create one “Service Bus” where all Services connect and expose their functionality. Good thing is that, in modern architectures, you can easily isolate specific service and then scale it they way you want (giving some specific service almost unlimited potential to handle requests or load). But GSB is another specific function of the modern Government architectures, and it deserve a separate post.
- Modeling is everything: you can model from the Ticket to the Cinema.(Actually I am not joking, but not everything requires or deserves to be modeled). Modeling something is actually describing the object of the modeling and setting some ground rules around it. That way, when you publish the model to the outside world, that same world knows how to work with your model (or here: object). It has massive advantages – again, too complex to be described here in a few words, but separate post.
With this, I guess we are moving forward to more understanding on why we need to think differently on the process of creating modern Government application portfolio, And again, we will create Government Services Catalog, not portfolio, but … next time.
