The most advanced AI agents today don’t run companies or negotiate contracts.
They write code.

Not because programming is easy, but because the environment around it is built around structure, tools, and fast feedback loops.

What’s happening in software engineering isn’t an anomaly.
It’s an early signal.

We’re looking for agents in the wrong places

When people talk about AI agents, they talk about what comes next.

Digital coworkers. Autonomous teams. Companies running themselves.

That framing misses what’s already happening.

It focuses attention on intelligence, when the real constraint has always been the environment the intelligence operates in.

The first place AI agents deliver real, repeatable value is software engineering.
Enough to permanently change the industry.

Why coding agents work first

This isn’t a sudden breakthrough in intelligence.

Coding agents work because software engineering is built for machines.

Code is structured, work happens through tools, feedback is fast and clear.

Work breaks into small steps that can be validated.

Repositories, terminals, CI pipelines, logs, tests.

A bounded workspace that contains the context.
Tools that let agents inspect that context and act on it.
Feedback loops that immediately show what worked and what didn’t.

That’s the environment coding agents operate in. It’s why they succeed there.

The work moves from execution to clarity

As execution gets cheaper, the bottleneck shifts.

It’s no longer writing code.
It’s deciding what should happen.

When agents can implement quickly, the cost of a vague instruction becomes obvious.
They do exactly what you ask. Including the parts you didn’t think through.

The hard work moves upstream.

Clarifying the work itself. What matters, what doesn’t, what “done” actually means.

This is where projects fail. Not because agents can’t execute, but because the system around them isn’t clear enough.

Bad code used to be the problem.
Now it’s unclear goals, fuzzy ownership, and implicit expectations.

When execution is cheap, clarity becomes the constraint.

What changes once execution gets cheap

Trying ideas no longer burns weeks of developer time.
You can explore, discard, and iterate without committing upfront.

That changes behavior.

Teams experiment more, they take smaller bets, they test assumptions earlier.

It changes how software gets built.

SaaS starts to feel heavy.
Building exactly what you need becomes cheaper than forcing existing systems to adapt.

It changes who builds.

People closer to the problem start creating solutions themselves.
Product managers.
Designers.
Operators.

Not because they suddenly became engineers, but because the cost of being wrong dropped.

Data and systems shift.

Instead of retrofitting RAG onto existing architectures, teams start designing data, interfaces, and context with agents in mind from the beginning.

Agents amplify lack of clarity

There’s a cold reality here.

When workflows aren’t clear, agents don’t bring order.
They just reproduce the chaos faster.

We saw this in practice.

In one system, an agent was given broad access to analytics data and asked to “figure things out”.

It worked.
The outputs looked reasonable.
They were wrong.

Not because the agent failed, but because the work wasn’t clearly defined.
There was no feedback validating results.

So it did exactly what the system allowed.

Agents aren’t general managers.

They need a clearly defined job.

That’s the foundation.

The pattern taking shape

Software engineering isn’t special.

It’s just first.

It was the first field where work became structured enough, tool-driven enough, and measurable enough for agents to operate reliably. Other industries are starting to follow.

Not because AI suddenly gets smarter, but because the work itself becomes structured the same way.

Clear, inspectable context.
Actionable tools.
Work broken into steps.
Fast validation.

Where that environment exists, agents work.

The companies preparing it now won’t be scrambling later.

We see this at Apoco while building agentic frameworks, protocols, and platforms for IBM Research.

The breakthrough isn’t the models.
It’s designing systems where agents can do real work without guessing.

The signal is already visible.

The real risk isn’t missing the AI wave.

It’s waiting too long to prepare the environment that makes it work. Inside your own organization.

Sunday Night: 40 Todos

Sunday was great in that quiet way. Long walk, a few good ideas, notes captured without trying too hard.

Then Sunday night I did the thing I always do: a quick peek at Monday. Things opened, and there it was - 40 todos staring back at me.

My stomach tightened. Not because the work was impossible, but because I could already feel the Monday morning shuffle starting.

I’ve used Things (Apple only) as my todo app for years because it stays out of my way. It’s on every device, and I keep the Today widget on my phone so I can glance and move on.

I keep it almost boring: 5 areas, 3 tags (quick, important, waiting), no projects. Just a clean list and a single place my brain can trust.

But that night the clean list didn’t feel clean. I closed the app and decided to build something.

I Built a Small Triage Skill

I built a tiny triage skill that reads my Things list and turns it into a 30-second briefing.

It talks to Things through an MCP server and runs in whatever I’m using that day - Claude Code, Cursor, any agent that supports MCP. It pulls the list, scans it, and applies a few dumb rules.

It groups by area, applies tags (quick, important, waiting), and flags anything blocked that needs a nudge. Then it suggests the next concrete move, not a re-org.

It felt like hiring a quiet side assistant. Not to do the work, just to set the table so I can start.

Monday Morning, Now in 30 Seconds

The real problem wasn’t the number of todos. It was the mental overhead of loading each one: what is this, how hard is it, how important is it, am I waiting on someone?

Before, I’d spend 15-25 minutes doing that sorting in my head. I’d open Slack already tired.

Now the list is already organized. I read a 30-second briefing:

Good morning! Happy Thursday.

"The effective executive focuses on contribution. He looks up from his work and outward toward goals." — Peter Drucker

🔴 Must do (4)

- Schedule share-out of AI-driven methods — 6 days old and tagged important. Don't be the blocker — even a quick video works. Get this off your plate today.
- Let the team know XYZ strategy — key strategic alignment your team needs now.
- Work with Joe & Doe on operationalizing technical strategy — iterative, but chip away today while momentum is fresh.
- Convert brainstorm into 3 bets + 3 next experiments - important. Capture it before the ideas fade.

🟡 Should do (2)

- Draft one hypothesis: “How enterprises will manage AI context in 3 years.” - strategic thinking that compounds.
- Decide where institutional knowledge lives - infrastructure decision that unblocks the team

🟢 Could do (5)

- Send XYZ to Ondrej — quick, 5 min max
- Kiddo's doctor appointment — quick personal items
- Resolve XYZ family account — quick personal errand
- A2A DeepLearning.ai — learning, explore if you have a gap
- Read one article from queue — learning snack

📋 Daily Routine

Answer all Slack messages
Read next chapter
Check XYZ Launchpad

That does one thing for me: it keeps me focused. I pick one important thing to anchor the day, and I let everything else be secondary.

Drucker’s point in The Effective Executive is that effective people don’t start with tasks. They start with their time and what only they can contribute. The triage runs before my morning starts. The list is already organized, the noise is gone. I just pick my focus and start.

Before: 15-25 minutes of mental shuffling.
After: 30 seconds and I know what to work on.

Under the Hood

Ok, here’s the actual technical part.

On the first run, it reads my Things areas and tags, asks a couple questions about my daily routines, then saves a local config file. It’s plain text and editable by hand.

Every morning after that, it does the boring maintenance: it categorizes uncategorized todos into areas, adds missing tags, creates any missing routine todos, then prints the briefing.

My tags are simple: quick (fits in a boring meeting), important (self-explanatory), waiting (blocked on someone else).

The output is always the same shape: Must do / Should do / Could do / Daily routine. It’s meant to be a 30-second read, not a dashboard.

It’s also idempotent (safe to run multiple times). It never deletes or renames. It only adds what’s missing.

If you want to try it:

npx skills add apocohq/skills --skill things-morning-organizer

It’s open source on apocohq/skills.

What’s Next

Next step is making it automatic: a scheduled task that runs every morning.
(Update: Done through launchpad. Automatically starts whenever you turn on your laptop in the morning. Feel free to reach out for guidance.)

I also want to ground it in context: who I am, what I’m optimizing for, what my company is working on. This is an unsolved problem for most teams using AI, and I’ll write about it separately.

I also want a meeting notes loop: integrate with tools like Granola, or just paste a transcript, extract todos, review them, and only then let anything land in Things.

Finally, I want better suggestions through a Drucker lens: what can only I do, and what should I delegate or drop?

If you want to contribute or follow along, I keep a full roadmap in the repo.

I still wake up to 40 todos sometimes. The difference is I don’t treat the list like the work anymore, and I start.

2025 was the year I made myself to step out of my comfort zone. I said yes to things that scared me a little.

I recorded my first podcast. I spoke at three conferences: Startup Disrupt, IBM Put AI to Work, and Data Day. At Data Day I talked about AI, protocols, and some of the architectural flaws people do not realize. Two ideas resonated the most:

• LLMs should not execute plans.

• LLMs should not transfer data.

I posted more on LinkedIn, and the feed grew from around 800 to 2k followers. I restarted blogging (I talk about the motivation in Writing Is How I Think).

At work, I leaned further into the CTO role. Less heads-down building. More representing the company, more decisions for the team, more standing in front of rooms.

At home, first skiing with our kiddo. Swimming classes. Safari. Boat trip.

What we actually built

Most of my time went into agentic systems (systems where an AI can use tools to actually do work, not just generate text) as part of a project for IBM Research. Some of what we shipped publicly:

1. ACP merged into Google’s A2A.

2. BeeAI Framework crossed 3k stars.

3. Agent Stack was the answer to agentic infrastructure.

4. I built a couple of personal agentic systems.

5. AI Fridays. We meet and discuss practical AI with the team. Best ritual.

6. We rebranded Apoco (logo and site design by Jan Broz).

7. We moved to a new office. Pragovka Art District.

8. Forbes Czech wrote about us.

9. A friend of mine joined, helping us with business development.

10. The team represented our projects on stages in Boston, Amsterdam, Orlando, and Stockholm.

11. We did have some fun along the way.

One opinion I earned the right to say this year, after hearing the same question at every event: MCP (a popular standard for plugging tools into agents) will not save your project. Tailored integrations focused on precision are what deliver value. Do one thing well.

What I didn’t choose

Some things in 2025 were not yeses I made.

I lost loved ones. I think about them often. I like the way Mexico thinks about the dead: as long as someone remembers you, you still live. I find some comfort in it.

My brother moved out of Prague. We used to live five minutes apart. Now it’s several hours of driving, and I’m still adjusting.

Biking was the steady thing through all of it.

Slowing down on purpose

By the end of 2025 I had to slow down. Nothing broke. I could just feel the engine running hot.

Too much FOMO around AI. Too much pressure I was putting on myself. Too many 30-minute blocks on the calendar where nothing real could happen. Too much trying to be a perfectionist.

So I stopped. I traveled. I read more. I gave myself nights and weekends back. I did a lot of thinking that I had been putting off.

What I noticed when I slowed down:

• I had neglected the team a bit. Stepping back to give them more freedom was the right call, but I let some of the leadership work slip.

• The deep work had moved to the edges of the week.

• The reading and thinking I needed had nowhere to land.

You have to slow down to run again. That’s the lesson I’m taking out of the year.

Rules for 2026

Not a wishlist. A small set of rules.

Deep work

• No news in the morning. No social feeds (I can post, I consume through my own curated feed).

• Read 30 minutes before bed.

• One protected weekly block to build agentic systems.

Public work

• Write once a month, even if it’s short. Write for yourself.

• One podcast per quarter.

• One uncomfortable yes per month.

CTO and team

• Share direction per quarter. Where we’re going, why, what success looks like.

• Put 1:1s back.

• One priority per week, done first. Drucker is right.

• Quarterly time audit. Time is life, no refill.

• Continue AI Fridays.

Personal

• Take a whole month off.

• Keep biking, 3 rides a week. Bike with kiddo. Print a map and explore together.

• Surprise my wife once a quarter.

• Celebrate. Wins, milestones, small ones too.

And one outcome I want: build one big thing that gets used by real users. Something to be proud of.

When I write, I slow down. I decide what matters. I follow an idea until it makes sense. It brings clarity and completeness.

That’s why I’ve kept writing, from my early days as a software engineer to my work today as a CTO.

Find the answer by writing

Any time I face a non-trivial problem, I write. Not to document an answer, but to find one.

I’m the type of person who needs space to think. I rarely form opinions on the spot. I need to think through the details, consequences, and tradeoffs.

Writing forces ideas onto the paper, where they either hold up or collapse. Very often, it shows me that I don’t understand the problem as well as I thought I did.

That moment is uncomfortable, but useful.

Break the loop and free space

In my head, ideas circle. Busy, but unproductive.

Writing interrupts that loop. It makes them line up.

Some survive. Some fall apart.

Once they are written, they stop demanding attention. I no longer have to carry them around or remember them.

That creates space. Space for new thoughts, new problems, or simply a bit of calm.

Discover what you did not know you knew

While writing, new angles appear. Edge cases surface that thinking alone missed.

A lot of what we know is unconscious. Writing pulls some of it into the open.

(As Paul Graham says1, there is no good substitute for that kind of discovery.)

Let it compound

The effects of writing are not immediate.

A single note rarely impresses. But notes, explanations, ways of thinking accumulate.

When I read books, writing about them is what makes it stick. Months later, those notes shape how I approach problems, often without me noticing.

The writing stays. And it quietly changes how I think.

Judgment in the age of AI

AI makes it easy to sound like you understand something you haven’t thought through.

It also makes it easy to generate words and code.

What it removes is the pressure to decide what matters and why.

Writing keeps the thinking mine.

In engineering, it is where intent and tradeoffs become clear.

When I prepare for public speaking, I write first, not slides.

While others outsource thinking to AI, clear thinking is becoming the advantage.

Taking responsibility for thinking

This is why I write.

Not to publish answers, but to take responsibility for my thinking.

In a world full of generated words, the scarce thing is judgment. Writing is how I practice it.

Over time, writing shapes what I pay attention to.
And what I pay attention to shapes who I become.

If I don’t write, I don’t trust my thinking.

When we first looked at A2A, we were asking whether it could support real systems, not just simple interactions.

Questions like:

• Can different teams build agents in different stacks and still interoperate?

• Can you understand and replay what agents did and why?

• Can agents access internal systems in a secure, policy safe way?

• Can you route, secure, and observe traffic without introspecting payloads?

• Can you stream partial results without breaking timelines?

• Can you evolve implementations without breaking existing agents?

• Can you support multi-agent orchestration patterns?

These are the questions that show up when agentic AI moves beyond demos and into production.

Some teams hit them because they genuinely need interoperability. Others hit them because leadership wants a shared AI standard.

In both cases, A2A is the most serious contender.

MCP solved integration. A2A is solving systems

MCP fixed a real enterprise problem.
Internal services were useful but hard to expose to AI. You needed technical context, tribal knowledge, and manual glue. Only a few engineers could work with them.

MCP changed that. It made internal services easy to wrap, easy to consume, and easy to extend.
Clear inputs. Clear outputs. One request. One response.
Perfect for tools.

Agents do not work like that.

Agents plan. They reason. They maintain state. They call each other. Their interactions are multi-turn, long-running, and open-ended.

MCP solved a narrow, well defined problem.
A2A tries to solve a wide, messy one.
It picks up exactly where MCP ends.

As soon as you move from “use a tool” to “work with another agent”, you need progress updates, lifecycle management, partial results, history, artifacts, and a shared understanding of how a task unfolds.

This is the gap A2A tries to fill.

What breaks when real systems adopt A2A

When we integrated A2A into Agent Stack, the problems did not appear at the beginning.
They surfaced as we built more agents and when other teams started writing their own agents.

Real systems surface problems that demos hide.

Here are the ones that mattered most.

1) Ambiguous semantics break interoperability

A2A treats Message and Artifact as separate concepts, but the boundary between them is unclear.
The same output can be modeled in multiple ways. Teams pick different patterns.

When semantics are unclear, implementations drift. SDKs try to support every variation, and interoperability suffers.

Streaming exposes this even more.
Because Messages cannot stream properly, developers are forced to use Artifact updates even when the content is not an artifact at all.

These are not theoretical issues.
They show up the moment multiple teams build agents independently.

We documented six related pain points and a path forward here:
👉 https://github.com/a2aproject/A2A/issues/1313

If you are hitting similar problems, a 👍 helps signal it to the steering group.

2) JSON-RPC does not fit enterprise routing

JSON-RPC puts routing metadata into the payload.
Enterprise routing needs it in headers.

Inspecting bodies is expensive, slow, and often impossible.
Duplicating metadata in both places creates drift and risk.

We hit this in 2023 while working with Red Hat on an inference service that routed model requests across data centers.
(That time we didn’t use JSON-RPC, but the problem was the same.)

Yes, we questioned JSON-RPC early on.
Some use cases may require non-HTTP transports, but the problem remains:
Enterprise-grade routing cannot rely on metadata inside payloads.

3) Extensions are an escape hatch, not interoperability

Extensions are useful. We rely on them.
Our Service Dependency Injection idea started as one:
👉 https://github.com/a2aproject/A2A/discussions/962

But extensions create dialects.

The moment two teams depend on different extensions, they are no longer speaking the same protocol.
They are speaking local variants based on assumptions and internal constraints.

Extensions are fine early on.
They cannot replace protocol design.
Use them wisely.

4) A2A is low level and lacks strong opinions

To build anything non-trivial, you need to understand multi-turn task lifecycle, skills and content negotiation, event queues, and state transitions. The protocol exposes all of these, but many of the semantics around them are loosely defined.

This creates real ambiguity. For example:

• In a multi-turn conversation between agents, is every turn a new Task, or is it one long-running Task with many events?

• When exactly is a Task considered “completed”? After the final message? After the final artifact? Only when the executor decides so?

• When should something be modeled as a Message vs an Artifact?

• Can artifacts still be streamed after a task has already completed?

Small differences in how teams interpret these do not break demos, but compound as you scale, especially across teams or services.

The ecosystem would benefit from stronger default opinions.

5) Most teams are not there yet

This is not a criticism. It is a reality.

Most teams still run:

• one agent, or

• a small cluster of agents inside a shared runtime, or

• A2A as a way to standardize shared UI or build an internal agent catalog.

Very few deploy agents as a distributed system across teams or services.
As a result, A2A often gets adopted for simpler use cases.

These are not what A2A was designed for.

The danger is that A2A hardens around early, non-representative use cases.
As more distributed agent systems emerge, A2A will need to adjust.
And early adopters may need to revisit choices.

How platform teams should approach A2A

Be honest about what you will actually need in the next 1–2 years.

• Choose one internal semantic model and stick to it.
  Drift happens when every team interprets the spec differently.

• Treat A2A as maturing infrastructure.
  Plan for change. Expect some rewrites.
  Build with loose coupling so you can switch out parts.

• Use A2A where it helps, not where it complicates.
  It shines in multi-agent orchestration and long-running tasks.
  It might be heavy for simple use cases.

• Accept that complexity comes from the work, not the spec.
  Long-running tasks, shared timelines, partial results, and agent coordination are genuinely hard problems. Distributed systems problems.

Even with gaps, A2A is the strongest shared standard we have.
The important part is giving feedback when the protocol gets in your way and sharing what real systems expose.
That is how the spec improves.

That is exactly why I said yes.

How it started

Over the last few years, our company grew and we started speaking more openly about the hard technical problems we work on.

We took those topics to meetups and conferences. The reactions surprised us. The things we shared resonated, and it felt like we were giving something genuinely valuable back to the community (not just showing slides).

That is how the Data Talk team reached out. They felt that what we were doing around agentic AI was practical and world class in a very non hyped way (their words, not mine).

The topic was obvious from the start. Who we are and what we work on. Agentic AI.

Why I said yes

I always try to push myself out of my comfort zone.

This felt like a good opportunity to do exactly that. I knew it would not be easy, and that I might struggle a bit (especially live, without edits).

But I also knew the benefits would be significant. Personally, and also for the company.

As I grew into my CTO role, I no longer speak just for myself. We are still a small company, but close to 30 people now, and I increasingly represent their work as well.

That means I need to be able to explain clearly what we do, why we do it, and why it matters. Not in slides, but in words.

How I prepared

I did not prepare by memorizing answers. I prepared by getting clear about the story.

First, I forced myself to pick a single topic. For me, that was the story of me, Apoco, and the kind of problems we work on around agentic AI (everything else was secondary).

I wrote a short retrospective of my path. Chronological. No polish. Just facts, projects, and decisions.

Then I highlighted a few things using different colors so I could scan it quickly. Milestones. Stories. Examples. Things that felt important.

From that, I picked three core topics I wanted to get across. Not more. I also made a short list of things I really did not want to forget to mention (mostly context that would be hard to recover on the fly).

I thought about the audience and what would actually be useful for them. And I thought about a simple CTA (nothing fancy).

That was it.

Some preparation is necessary. Too much preparation kills authenticity. The goal was not control, but clarity.

How it went

It went great.

The moderator (Jirka Vicherek) was friendly and well prepared. I shared my preparation document with him in advance, which helped set the tone.

Even though I had notes ready, I did not look at them once. The conversation flowed naturally. It felt more like a focused discussion than a performance.

Everything was recorded in one take. No cuts. It took longer than I expected, but that was a good sign.

If you are curious, you can listen to the episode here 👉 (the episode is in Czech):

I am currently planning a separate podcast episode in English on a similar topic. It is still in preparation, but coming later

What worked, what didn’t

I still made some mistakes.

I think I talked too much (especially my brother thought so). The intro was probably too long and too personal. The story matters a lot to me, but it might not have been the most relevant starting point for everyone listening.

That was a good reminder.

If someone gives you their time, they expect something in return. Insight, context, a new way of thinking. Not just your backstory.

A few things I would keep in mind next time:

Do:

• Be yourself. Nothing matters more than being authentic.

• Think about the audience and the bigger picture.

• Stay concrete. Stories over abstractions.

• Slow down when something matters. Silence is fine (introverts often rush when they should not).

• React naturally. If you are genuinely excited about something, let it show (even if it feels a bit awkward).

Don’t:

• Overprepare or try to control the conversation.

• Do not optimize for sounding smart. Instead, optimize for being understood.

• Repeat the same words or ideas over and over.

• Drift into abstractions when a concrete example would work better.

• Forget why people are listening in the first place.

What I got out of it

The biggest long term benefit was clarity.

If someone asks me about my story now, I can give them a short, coherent answer. And if they want more context, I can point them to the Data Talk episode instead of trying to compress everything into a few sentences.

Going through the preparation and the conversation helped me sort my own thoughts. It forced me to articulate not just what we do, but why we do it.

That matters personally, but it also matters for the company. It makes it easier to explain our work.

And on a more personal note, my parents and family got to hear what I actually do for a living (even if they forgot most of it already).

Would I do it again

Yes.

I will.

I enjoyed it. It pushed me forward.

And I want to keep doing it. Another podcast is already in planning (this time in English). Stay tuned.

Node.js comes with a built-in library that allows applications to act as a web server. Thanks to its event-driven architecture and a non-blocking I/O API that optimizes an application’s throughput, Node.js excels when it comes to real-time communication. The following are advantages of Node.js:

• It is very lightweight and fast.

• It is easy to configure and highly customizable.

• It comes with the npm package manager that contains 140.000+ packages that are available for free, and it handles dependencies excellently.

• It removes silos that existed between frontend and backend developers, making the development process more effective. Backend and frontend teams can be merged into one unit.

• It allows one to build the application in JavaScript “top-to-bottom”, even down to the database level if NoSQL DB that stores objects in JSON (like MongoDB or Cloudant) is used. This makes development and even hiring significantly easier.

• It is capable of handling a huge number of simultaneous connections with high throughput. Therefore, it excels in building fast and scalable network applications.

• It allows code to be reused across the client-side and server-side of the application.

• Even though Node.js is initially designed without threads, one can still take advantage of multiple cores and spawn child processes using ChildProcess API.

Blocking I/O vs Non-blocking I/O1
Blocking example
An example of blocking is how some web servers like ones in Java or PHP handle requests. If your code does something blocking, like reading something from the database, your code “stalls” at that line and waits for the operation to finish. In that period, your machine is holding onto memory and processing time for a thread that is not doing anything. In order to cater other requests while that thread has stalled depends on your setup. Your server can spawn more threads to cater the request or, if you have a load balancing setup, forwards requests to the next available instance. This instills more setup, more memory consumed, more processing.

Non-blocking example
In contrast, non-blocking servers like ones made in Node.JS, only use one thread to service all requests. This might sound counter-intuitive, but the creators designed it with the idea that the I/O is the bottleneck i.e. not computations. When requests arrive at the server, they are serviced one at a time. When the code serviced needs to query the DB for example, it sends off a request to the DB. However, instead of waiting for the response and stall, it sends the callback to a second queue and the code continues running. Now when the DB returns data, the callback gets queued in a third queue where they are pending execution. When the engine is doing nothing (stack empty), it picks up a callback from the third queue and executes it.

Node.js has one disadvantage – it is not designed for heavy computations as any CPU intensive operation annuls all of the throughput and any incoming request is blocked while the thread is busy crunching numbers.

“How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node.js operates on a singlethread, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections (held in the event loop). A quick calculation: assuming that each thread potentially has an accompanying 2 MB of memory with it, running on a system with 8 GB of RAM puts us at a theoretical maximum of 4000 concurrent connections, plus the cost of context-switching between threads. That is the scenario you typically deal with in traditional web-serving techniques. By avoiding all that, Node.js achieves scalability levels of over 1M concurrent connections.”2

“iBeacon is an indoor positioning system that Apple Inc. calls “a new class of low-powered, low-cost transmitters that can notify nearby iOS 7 devices of their presence.” They can also be used by the Android operating system (limited to central-only). The technology enables an iOS device or other hardware to send push notifications to iOS devices in close proximity.”

The iBeacon works on Bluetooth Low Energy (BLE), also known as Bluetooth Smart. Bluetooth LE can also be found on Bluetooth 4.0 devices that support dual mode. In a real life scenario it would be more of a location-aware, context-aware, pervasive small wireless sensor beacon that could pinpoint users’ location in a store: iBeacons could send notifications of items nearby that are on sale or items customers may be looking for, and it could enable payments at the point of sale (POS) where customers don’t need to remove their wallets or cards to make payments. It could be a possible Near Field Communication (NFC) competitor.

To understand how iBeacons work, we need to start with BLE.

BLE – Bluetooth Low Energy

iBeacons use BLE (Bluetooth Low Energy) technology also marketed as Bluetooth Smart. BLE was introduced under the name Wibree by Nokia in 2006 and is part of the Bluetooth 4.0 specification since it was merged to Bluetooth standard in 2010. BLE uses different protocol than Classis Bluetooth and therefore is not backwards-compatible. Bluetooth LE uses the same 2.4 GHz radio frequencies.

So except Classic Bluetooth, we have 2 more types of Bluetooth peripherals:

• Bluetooth Smart Ready – dual-mode device compatible with both Classic and LE

• Bluetooth Smart – LE-only device which is not compatible with Classic Bluetooth

Most of the newest mobile devices and computers support Bluetooth Smart Ready (so both Classic and LE protocols). iBeacons are (usually) LE-only devices and therefore not compatible with older Classic Bluetooth.

The biggest advantage of BLE is its low energy consumption. This enables iBeacons to transmit a signal continuously on a single button cell battery for a couple of years (usually 2-3 years). As with the Classic Bluetooth, LE can reach up to 100 meters.

How does BLE communication work

Without going too deep into details, there are two modes of communication:

• advertising – one-way discovery

• connecting – two-way communication

iBeacons use only advertising mode and I’m not going to talk about connecting mode (for those who are interested, you can look at Apple’s Core Bluetooth guide). As I said before, iBeacons run in the advertising mode. This means they periodically send packets of data that can be received by other devices like smartphones or tablets. iBeacons behave like a beacon that is only sending “Here I am!” signals and not listening. This messages can be transmitted in intervals from 20 ms to 10 seconds and the longer the interval, the longer is the battery life.

Packets

iBeacons transmit packets and its size can by up to 47 bytes. Following is a diagram of this packet broke down to particular blocks.

So the BLE packet in advertising mode consists of:

• Preamble (1 byte)

• Access Address (4 bytes) – always 0x8E89BED6

• PDU Header (2 bytes)

• PDU MAC address (6 bytes)

• PDU Data (0-31 bytes)

  • iBeacon prefix (9 bytes)

  • Proximity UUID (16 bytes)

  • Major (2 bytes)

  • Minor (2 bytes)

  • TX power (2 bytes)

• CRC (3 bytes)

The most important block for us is the PDU Data. Following is an example of this block split into sub-blocks:

02 01 06 1A FF 4C 00 02 15 # iBeacon prefix (fixed)
B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D # Proximity UUID
00 49 # Major
00 0A # Minor
C5: 2’s complement of measured TX power

Let’s explain meaning of each block (line):

iBeacon prefix (1st line) – these are 9 fixed bytes with the following meaning. iBeacon prefix indicates that this BLE device is actually an iBeacon device.

02 # Number of bytes that follow in first AD structure
01 # Flags AD type
06 # Flags value
1A # Number of bytes that follow in second (and last) AD structure
FF # Manufacturer specific data AD type
4C 00 # Company identifier code (0x004C == Apple)
02 # Byte 0 of iBeacon advertisement indicator
15 # Byte 1 of iBeacon advertisement indicator

Proximity UUID (2nd line) – is an identifier that distinguishes your iBeacons from the others. Your mobile app is then set up to listen just to this proximity UUID.

Major (3rd line) – is used to group a related set of iBacons.

Minor (4th line) – is used to identify individual iBeacons.

2’s complement of measured TX power (5th line) – actual TX power can be calculated as a 2’s complement: 0xc5 = 197 => 256-197 = -59 dBm. TX power is the strength of the signal measured at 1 meter from the iBeacon. This number is then used to determine how close you are to the iBeacon. The calculation is based on the fact that you know TX power (RSSI at distance of 1 meter from the iBeacon) and current RSSI (Received Signal Strength Indication). iOS does the calculation for us. Other platforms need to calculate it – the only one example I found: http://stackoverflow.com/questions/20416218/understanding-ibeacon-distancing

So what exactly iBeacon is?

It’s a Bluetooth LE device with the specific packet format. Other devices recognize iBeacon by the PDU Data block (exactly by the first 9 bytes of this block) and based on this data block can determine their distance from the iBeacon. This means, that every device capable of BLE can be turned into an iBeacon. iBeacons are widely used for micro-location purposes (especially inside buildings where GPS or other technologies aren’t capable of accurate results).

In the next article, I will show you how to turn your smartphone, tablet or laptop into an iBeacon transmitter. I’m also exploring how machine learning could be used together with iBeacons in order to locate devices inside buildings.

Where to get iBeacons

• https://kontakt.io

• https://flybuy.com

• https://estimote.com/

• and more…

“DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.”

I see DevOps as a philosophy that helps increase delivery speed and quality via frequent, automated releases. Many companies are adopting agile practices and tries to reduce customer feedback cycles. These companies usually come to the point when development teams successfully follow the agile practice (produce software incrementally in short time cycles), but they are struggling with the delivery process. They are not able to rapidly and more frequently deploy software to many different environments, they need a continuous delivery pipeline from development to operations, and all the way to production.

For example Flickr developed DevOps capability to support a business requirement of ten deployments per day; this daily deployment cycle would be much higher at organizations producing multi-focus or multi-function applications (think about Google, they do many releases every day but most of them are not noticeable). This is referred to as continuous deployment or continuous delivery.1

While DevOps is an approach and not a set of tools, the adoption of the DevOps philosophy can be greatly aided by having the right tools. In April 2013, IBM acquired UrbanCode company and strengthened its DevOps portfolio by tools as uDeploy and uRelease. But I will talk about these tools in another article.

Why DevOps?

In 2013, IBM Institute of Business Value made a study2 saying that 54 % of companies believe software delivery is critical but only 25 % leverage software delivery effectively today. In the end 69 % of companies outperform those who don’t adopt DevOps approach.

Challenges of software delivery

• Costly, error prone manual processes and efforts to deliver software across an enterprise

• Slow deployment to development and test environments leave teams waiting and unproductive

• Higher risk due to managing multiple application configurations and versions across servers

Benefits

• Drive down cost by automating manual tasks, eliminating wait-time and rework. It reduces the amount of manual labor, resource wait-time, and rework by eliminating errors and providing self-service environments.

• Speed time to market by increasing the frequency of software delivery through automated, repeatable, deployment processes across development, test and production.

• Reduce risk through increased compliance of application deployments. It delivers higher quality application releases with increased compliance through end-to-end transparency, auditability and reduced time to feedback.

• Reduce errors: Automated software release and deployment

• Improve productivity: Push-button deployments for developer and operations

• Compliance and auditability: Enforced security and traceability

Conclusion

DevOps enables organizations to rapidly and more frequently deliver applications to market with reduced cost, risk and increased quality. It’s helping organization realize the value of agile with continuous software delivery.

IBM Cognos Business Intelligence is part of the IBM Business Analytics solution. It provides a unified workspace for business intelligence and analytics that can be used to answer key business questions and outperform the competition. With IBM Cognos BI, users can:

• Easily view, assemble and personalize information

• Explore all types of information from all angles to assess the current business situation

• Analyze facts and anticipate tactical and strategic implications by simply shifting from viewing to more advanced, predictive or what-if analysis

• Collaborate to establish decision networks to share insights and drive toward a collective intelligence

• Access information and take action anywhere, taking advantage of mobile devices and real-time analytics

• Integrate and link analytics in everyday work to business workflow and process

IBM Cognos BI consists of these tools:

• IBM Cognos Business Insight
  Web-based tool which allows you to use Cognos content and external data sources to interact, analyze and build sophisticated interactive dashboards that facilitate collaborative decision making.

• IBM Cognos Business Insight Advanced
  Web-based tool that allows you to analyze your data. The user interface is designed to help business users gain insight into their business. You can create reports with relational or dimensional data sources, and than show data in lists, crosstabs, and charts.

• IBM Cognos Framework Manager
  Desktop application for importing data definitions and modeling that information to provide simplified data access for business reporting and analysis. Models can be published as packages and deployed to Cognos 10, where users can create reports based on the package content.

• and others – IBM Cognos Report Studio, IBM Cognos Query Studio, IBM Cognos Analysis Studio, IBM Cognos Event Studio, IBM Cognos Metric Studio, IBM Cognos Administration (for more info about these tools check Handbook – link below)

Basic Architecture

Following diagram displays basic architecture describing relations between Framework Manager, Business Insight, and Business Insight Advanced. Very briefly, Framework Manager provides simplified data access to Datawarehouse, Business Insight Advanced then offers capability to create reports based on the model created in Framework Manager (these models are published to Cognos as packages), Business Insight can create interactive dashboards consisting of reports from Business Insight Advanced and additional external data as excel files.

Framework Manager Architecture

Framework Manager is a desktop application for modeling metadata which provides simplified data access for business reporting and analysis. Models are published as packages and deployed to Cognos.

Business Insight Advanced Architecture

Business Insight Advanced is a web-based tool that allows you to create reports with relational or dimensional data sources, and than show data in lists, crosstabs, and charts.

Business Insight Architecture

Business Insight is a web-based tool which allows you to use Cognos content and external data sources to interact, analyze and build sophisticated interactive dashboards that facilitate collaborative decision making.

Original Presentation

Original presentation about our project is available on slideshare:

👉 https://www.slideshare.net/slideshow/business-intelligence-in-ibm-cognos-10-utc/15242505