This is where I share some of my ideas, experiences and previous work. I hope that you find it useful. Huseyin Ozel

My Most Recent Posts

Wednesday 18 March 2020

As in many other terms in technology and especially within the domain information technologies, IoT is one that is ubiquitously used and usually vaguely agreed upon for what it stands for but rarely articulated. In this sense, it is a bit like the term 'cloud'.

Photo by Denys Nevozhai on Unsplash

During my work as a technology consultant, for a while I was in charge of pre-sales activities on Internet of Things in the EMEA region. So, this included presenting my employer's IoT-related portfolio to corporate clients, but also to colleagues and account teams internally.

The main difficulty I noticed was that almost everyone had a different imagination on the extent of IoT as a technological system and what my employer could be offering from its overall portfolio.

The consultancy organisation I worked at actually had an IoT reference architecture in place and it was work in progress as a new version was underway. An overview of the reference architecture was constantly being used at internal and client- or partner-facing conversations. What I came to realize about the reference architecture, however, was that it lacked a logical view that both technical and non-technical audiences could relate to, as a starting point of discussions.

It was obvious that there was a need for setting the big picture first on IoT before moving onto providing details on what we were doing within this big picture. That's when I built my logical framework (4C2S) to articulate IoT and I really worked wonders both in external and internal conversations when selling and collaborating.

Without diving into too much technical detail, here I will provide an overview of 4C2S framework hence it is suitable for public sharing as it was used in open external conversations, presentations and discussions.

IoT essentially is a technological setting that allows connecting things to a network so that some data from those things could be collected and analyzed. Analyzed data would hopefully provide some insights, based on those which some actions could be ordered to be taken by things or some human processes could be enriched.

So, there are 4 main steps in an IoT setting:
  1. Connect: Facilitate network connectivity on things by utilizing embedded and/or built-in sensors.
  2. Capture: Collect and relay relevant data from the things that are connected.
  3. Comprehend: Analyze the captured data in order to make useful meanings out of it.
  4. Create: Derive value with the meaningful insights, either by feeding orders back into things (actuators) or by making human processes more informed.
The framework lists these 4 steps as vertical dimensions in their sequence. As in any functional system being built for a purpose, there is need for planning, construction and maintenance. Hence, there needs to be a lateral dimension for servicing the system that runs across the vertical steps. Additionally, a major valid concern for IoT is end-to-end security, hence securing the system deserves its own layer outside regular servicing. So, yet another lateral dimension, security, is to run across the steps of the IoT actions.







Tuesday 17 March 2020

We constantly live in the midst of projects. Personal bucket list items such as taking that trip to that destination eventually, writing that book we always imagined, building that birdhouse on the tree in the backyard, and then there are those things we plan to do as the family, and those things we plan to do with friends and most typically we have all those projects going on at the workplace.



As I personally like keeping many ideas active, I get curious about many things in life in different stages, my list of projects tend to be quite long. Starting a blog was one for very long time until I could find time to sit down and write during the corona-virus crisis that kept me at home for long durations of time.

An obvious challenge, at least in my case, is keeping a track of those ideas and projects. At what stage they each are, how far they are from being realized and in some cases what is even contained in each one of them as things get forgotten since they became a project.

I observe that this challenge is not necessarily a personal one. It really is quite common for businesses as well.
There are zillions of material out there on agile vs traditional. So, I don't want to bore my readers by writing yet another one. One point of frequent debate is how would one judge when agile is good over traditional.


Photo by Jeremy Lapak on Unsplash

First off, I am not sure if it still a good idea to use the term 'traditional' any longer when referring to staged project management. Agile methodologies have been around for quite a while now, so they are not necessarily something very new any longer. So, I don't think that we could label agile methodologies as very modern ones hence the staged methodologies stay 'traditional'. They both exist and are still being used for very good reasons; they went through certain evolution along the years hence I would argue that they are as modern as each other.

The main point to understand really is on which cases the staged project management or the agile methodology would suit our needs better.

I promised that I will not really dive into the comparison of agile vs staged in this article. A quick check on the most basic differences however will really help me lay the foundation for my further arguments.

The following table really encapsulates the main differences between the two at a very high level.


Popular Posts