Frameworks, Libraries, Services, Platforms

A recent conversation happened in my workplace about how one defines a framework. More often than not, software developers and architects tend to call their code as "frameworks" if it is reused (or in many cases, they they can potentially be reused without any proof) across multiple applications.

A quick search through Stack Overflow provided an explanation I thought was helpful.

When writing code:

• eventually you discover sections of code that you're repeating in your program, so you refactor those into Functions/Methods.
• eventually, after having written a few programs, you find yourself copying functions you already made into new programs. To save yourself time you bundle those functions into Libraries.
• eventually you find yourself creating the same kind of user interfaces every time you make use of certain libraries. So you refactor your work and create a Toolkit that allows you to create your UIs more easily from generic method calls.
• eventually, you've written so many apps that use the same tool kits and libraries that you create a Framework that has a generic version of this boilerplate code already provided so all you need to do is design the look of the UI and handle the events that result from user interaction.

From http://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library

Another reference puts this in a visual context:

http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks

Additional thoughts

One interesting point made in the second post is that a telling (but not necessarily the only) characteristic of a framework is that it has Inversion of Control (it calls the app than the other way around). Frameworks tend to do a lot of the 'plumbing' work that is necessary for a software application while the developer needs to focus only on extending or leveraging the work at the right places (knowing where to put the faucets, in the plumbing analogy).

What is probably missing in this picture is the notion of a "service", but in this context, it can simply be taken as a more abstract form of a "library", as it possesses the same characteristics.  If a use of a library spans across multiple platforms and technologies, it can potentially be abstracted further as a service.

The description below also nicely conforms to the "three-box principle" that I learned a long time back, which states that you cannot get to libraries / tool kits / frameworks without having done or at least thought through multiple (at least three) implementations.

"Three Buttons" of Information Management

Recently, I came across this talk through my LinkedIn. The talk was given at the Adobe Symposium (2016) by Mr. Jones Lukose, a Senior Information Management Officer at theInternational Criminal Court of Justice at Hague. My comments are below the video so as to minimize any bias before you get a chance to view it first. I do request that you view the video first before reading further so as to get the appropriate context.

 

Keynote Jones Lukose ICC - Adobe Symposium in Amsterdam 2016

Observations:

The talk, to me, is a great example of how powerful a good story can be in engaging audience and making the message 'sticky'. When the talk started, you can see the audience generally restless or bored - likely due sitting through various sessions. Even a couple of ice breakers that the presenter made seemed to only provide some awkward silence. But then, the moment he says "I want to tell you the story of three buttons", the mood suddenly seems to change. It is not a boring lecture anymore, but a 'story'! You can see the audience suddenly paying attention to the video and get fully engrossed subsequently. The thick accent the presenter has doesn't seem to bother anyone - because the story was so compelling and engaging.

The crux of the presentation itself was simple, but to the point. A good Information Management system should have three things at its core:

1. It should preserve information
2. It should provide value around the information that is managed
3. It should facilitate orchestration around the information

I felt the choice of words was important because it goes beyond simply boiling it down to "storage", "insights", and "collaboration", as typical marketing jargon is prone to do. Each goal goes much beyond these catchphrases and more importantly, are from the perspective of the end user - a critical component that is often missed in ECM implementations.

I noted down the following takeaways from the presentation. Obvious as they may be in hindsight, they are most often ignored in the heat of getting a project completed:

1. Listen carefully to your end users: We often tend to have preconceived notion about what the customer wants or can have, driven by either corporate policies, vision, technical limitations, or what have you. But at the end of the day, if the system does not do what the end users want (may not be your direct customers), it will not get adopted. ECM solutions often suffer from this malady. We tend to look at various features without getting appropriate insight into the context in which those features are used to fully appreciate their usefulness. As a result, a solution gets deployed that is not aligned with the user's flow.
2. Develop guiding principles to achieve scale: Scalability is not achieved on the first day. It is achieved over time. However, in order to support scalability it is more important to establish a set of guiding principles that will govern the architecture than to anticipate and devise and architecture that will potentially be scalable from the start. The guiding principle that the presenter created - "every feature should build trust" - is a great example. It is broad enough to be applicable across various scenarios, while being specific enough to be able to test the outcome, and pithy enough to be a principle.
3. Pause: Whether it was natural or intentional, the presenter paused throughout his speech on various occasions, especially during exciting points in his narrative that provided a cliffhanging feeling. We often are so compelled to get our message across that we forget to pause and give a moment for the listener to ingest. A pause builds expectation, excitement, and oxymoronically, momentum.
4. A good story is more powerful than a great message: If the presenter had gotten on the podium and started talking about the three critical features of an Information Management system, it would've been a snooze fest. Instead, he wrapped the message into a story and pulled the audience along for the ride. When he narrated the story, we were walking in the corridors of ICC with him. WE could visualize the judge sitting motionless in front of a monitor that was all wrapped up. WE were engaged and ready to listen to whatever he would say next. This made the story sticky.
5. Keep it concise: The 30 minute presentation was just about the three bullet points mentioned earlier. Nothing more. This gave enough room to build a story around the message. We often tend to cram the time we get with a number of messages that we try to convey that it becomes an information overload for the audience. At the end, none of the messages end up registering in their memory. It is far better to let them remember a few things than attempt many and leave with none.

I hope you enjoyed the talk as much as I did.