Saturday, April 05, 2014

The End Of Ubuntu One - What It Means

Although a big fan of Ubuntu Linux as a desktop OS, I've never been interested in their cloud storage platform Ubuntu One, and found it a bit of a nuisance when asked to sign up for it every time I installed the OS.

Now Ubuntu One is being shut down. I'm 'meh' but still a bit surprised.

The linked article talks about mobile, and how new mobiles such as the Ubuntu-powered ones need cloud storage to succeed. If so, isn't it really bad timing for Canonical to walk away from a fully operational cloud platform just when its mobile devices are entering the market?

Ubuntu-powered smartphones
(Do you know what the time on the middle phone refers to?)

I think it's about economics.

Ubuntu's statement says:

If we offer a service, we want it to compete on a global scale, and for Ubuntu One to continue to do that would require more investment than we are willing to make. We choose instead to invest in making the absolute best, open platform and to highlight the best of our partners’ services and content.
Hmm. I read this as Canonical trying to build a partner ecosystem that will substitute for having a big cloud-and-mobile story like Google does, without the investment that such a proprietary ecosystem will require. Let's see if they succeed.

The other side-story in the linked article is about telcos and their role. Having worked at a telco over the last two years, I can confirm that the major fear in the telco industry is being reduced to commodity carriers by "over the top" services. The telcos are fighting to offer content, and will want willing mobile wannabe partners like Mozilla and Canonical to offer smartphone platforms that will work with networking infrastructure and make the telcos more attractive (through content that both players source from content providers). It will be interesting to see how this four-way, federated partnership (between multiple telcos, independent smartphone platform vendors like Mozilla and Canonical, smartphone device OEMs and content providers) will play out. Many of these companies will think of themselves as the centre of the Universe and the others as partners.

"Nothing runs like a fox" - Well, let's see if the Firefox Smartphone has legs

In the meantime, some good news for startup cloud providers ("startup" only with respect to the cloud, since they will still need deep pockets to set up the infrastructure!): Canonical is open-sourcing its Ubuntu One storage code “to give others an opportunity to build on this code to create an open source file syncing platform.” This should be interesting.

Tuesday, March 11, 2014

Tools for HTML Table and Browser-Side Database Manipulation

I've been having a lot of fun building a realistic-looking demo app that is meant to showcase the features of a coming product. A big challenge in such cases is obviously dynamic data, since hard-coded data won't cut it. It needs to behave like a web app, providing the illusion of a server-side database, but without a server-side database.

HTML5 provides built-in client-side persistence features called sessionStorage and localStorage, but when the data requirements are complex, as in my application, these just aren't adequate. What I need is a client-side database like SQLite. As it turns out, different browsers have taken different routes to providing client-side databases, and it made my head hurt to read about Web SQL and SQLite and which browser incorporated which database and which browser abandoned which database. Finally, I found a JavaScript library called HTML5SQL.js that promised to abstract all those implementation issues from me, giving me a standard API to work with.

So far, it's worked great for me and seems very powerful and flexible. So that's the first tool I'd recommend, for client-side database manipulation - HTML5SQL.js.

Then I had the challenge of building HTML tables that would display this data, allow the user to manipulate it visually and save changes. After a lot of searching, I found another nice JavaScript library called DataTables. DataTables provides lots of powerful features, including sortable columns and pagination. These work even in the default settings with no configuration.

So that's the second tool I'd recommend, for HTML table manipulation - DataTables.js.

By blending HTML5SQL and DataTables functions, I could create HTML tables from a client-side  database. Even better, I could open multiple tabs on the browser, each representing a different part of the application, and they could all see the same data, because the database is a global resource to all tabs in the browser. Best of all, the data stayed persistent across browser restarts. It's a true database, with persistence, relational structure and SQL smarts.

Other tools:

Needless to say, jQuery has now become required technology, and a web developer simply cannot leave home without it. It's so powerful I'm still looking for the right categorisation to describe it.

Many of the new JavaScript libraries are built in an asynchronous style, so a rather naive usage assuming synchronous behaviour (that a function invoked first will complete before the next invoked function) will lead to some surprises. If you need to ensure that two asynchronous functions are executed in strict sequence, you will need to resort to callbacks, as explained on StackOverflow.

For visual designers, the old method of using HTML tables to lay out components is now passé. Using CSS layouts is the in thing. A popular CSS layout framework is called the "960 Grid System", or It's named for the fact that most modern screens have a width of at least 960 pixels, and this number lends itself to being divided into 12 or 16 columns with spaces or gutters in-between. A newer one is unsemantic, which is said to be better for "responsive" UIs (those that adapt to different screen sizes, such as desktop browsers, tablets and mobile phones), but is a bit more complex to use. In both these frameworks, HTML components such as "div" and "table" elements just need to be given special class names, and the CSS then uses these to lay them out. It's quite neat and powerful, but I'm not working in that area because I'm not a graphic or layout designer. I've just seen the nice effects you can get with a CSS layout framework.

Saturday, February 15, 2014

Sydney Workshop "Introduction to Dependency-Oriented Thinking" Held

After weeks of hectic preparation, Rahul Singh and I held our long-awaited workshop today on "Dependency-Oriented Thinking", comprising all-new material from my recent document "Dependency-Oriented Thinking: Vol 1 - Analysis and Design".

Somewhat disappointingly, we only had three signed-up participants, but the numbers only tell half the story. Only one of the three was from Sydney. One flew in from Melbourne the night before, and another got up at 4 am to make the 3+ hour drive from Canberra to Sydney. With such determination on their part, I just had to do my best, and I hope they were happy with the workshop. They certainly expressed satisfaction on their feedback forms :-).

The slides are now available on Slideshare. If anyone was put off from reading the original document on account of its size (264 pages), they could go through this slide pack instead (only 220 slides, heh).

Tuesday, January 21, 2014

Sydney Workshop On Dependency-Oriented Thinking (Saturday Feb 15, 2014)

Well, it's time to road-test my SOA method "Dependency-Oriented Thinking". I released the two DOT documents before Christmas, Volume 1 on Analysis and Design and Volume 2 on Governance and Management. Now, Rahul Singh and I are conducting an all-day workshop to provide a more interactive instruction into the Analysis and Design aspects of the method. It'll be on Saturday the 15th of February, 2014.

The course fees are $450 plus GST for the all-day program. There's an early bird price of $400 plus GST for those who register on or before the 3rd of Feb.

You can download the workshop brochure and schedule here:

If you're a Sydney-based business analyst, solution architect or senior designer, you may be interested in this workshop. My objective is to make IT professionals more effective by helping them think more powerfully about complex, inter-connected systems. Dependency-Oriented Thinking is just structured common sense, but it doesn't come naturally. It needs to be taught, and it requires practice before it can become second nature.

Wednesday, December 25, 2013

Dependency-Oriented Thinking - Documents Released!

I know I haven't been active on this blog for almost 6 months, but I haven't been idle. Ever since Rahul Singh and I conducted our first workshop on "Dead Simple SOA" in Sydney last year, I have been working on the feedback we received, namely that we needed to split "Analysis & Design" from "Governance & Management" because these two topics are of interest to two different audiences.

Splitting out just Governance & Management from the original document "Slicing the Gordian Knot of SOA Governance" was the easy part. I realised that I didn't have much material on Analysis and Design, so I had to write that from scratch. That task ultimately took the better part of a year.

Well, that's completed now, and the two documents are now ready to download from SlideShare:

I have believed for a while now that the core concept behind SOA ought to be "dependencies". I could explain more here, but I'm exhausted after the marathon effort of the last few months. Besides, you'll find a very detailed argument in Volume 1.

Please do download these documents and have a read. More importantly, give me your feedback. My email address is in the "About the Author" section in both documents.

Tuesday, July 02, 2013

Dependency Principles

I've been used to thinking of SOA as "Dependency-Oriented Thinking" for such a long time that it suddenly struck me that I should readily be able to postulate "dependency principles" that can be applied at each of the BAIT layers. As it turned out, I was fortunate enough to have some actual case studies to verify my proposed set, and these cases were selected for being representative of different tiers, so they were quite comprehensive.

It turns out that the lesson to be learnt after a post-mortem of each of those case studies was that one or more dependency principles had been ignored or violated, resulting in the problem that was being faced. The corollary is that an organisation that scrupulously adheres to these principles will end up achieving SOA.

So, without further ado, here are the dependency principles (updated on 25/12/2013):

Business Layer Principles

1. Traceability – Enforce core governance; ensure that everything that is done makes sense with respect to the organisation's Vision
2. Minimalism – Challenge assumptions, reject unwarranted constraints, do no more than required, reuse functional building blocks
3. Domain Insight – Understand the true nature of the business; don't be misled by superficialities or conventional wisdom; re-imagine the business from first principles
4. Business Process Coordination Style – Choose a coordination style (orchestration or choreography) based on whether tight control is possible and/or necessary. This influences the choice of technology standard (SOAP or REST), but may also be influenced by a prior choice of standard.

Application Layer Principles

5. High Cohesion (“Belonging”) – What belongs together should go together, with minimal links between distinct systems; question instances of a single logical function split across multiple systems, or multiple logical functions combined within a single system. Group operations that share a Domain Data Model and business logic into Products, those that share an Interface Data Model into Services.
6. Decoupling of Interfaces from Internals – Ensure that no external system develops dependencies on the internal aspects of a system; create an interface to isolate the systems from each other.
7. “Goldilocks” Signatures (Stability versus Precision) – Identify multiple concurrent flavours of each logical operation; establish a way to express the business intent common to all of them; make sure that the interface doesn't change for minor variations in logic but does change with the business intent.
8. Shared Semantics (Negotiation of Intent and Content) – In choreographed processes, ensure that the service provider and service consumer understand the meaning of every Operation as well as the mechanics of how each Operation should be invoked.

Information (Data) Layer Principles

9. Decoupling of Interface Data from Internal Data – Distinguish the Interface Data Model from the Domain Data Model; use this to guide the grouping of Operations into both Products and Services
10. Isolation of Context from Content – Separate the core data elements of the Interface Data Model from its qualifying elements; establish a separate Type Hierarchy for Context; use Context to categorise Variants and minimise Versions
11. Low External Coupling (“Need to Know”) – Expose the minimum possible set of data to service consumers; make the data as generic as possible but exposing the business intent (i.e., conforming to the “Goldilocks” signature).
12. Type Hierarchy – Create a data type hierarchy for both Content and Context elements; use this to expose multiple Variants as a single logical operation
13. Identity Association – Ensure that entity identifiers do not leak out through the interface; provide a mapping between external and internal identifiers.

Technology Layer Principles

14. Extraneous Constraints – Avoid introducing fresh dependencies between unrelated components in the process of implementing business logic
15. Logic Bundling – Avoid combining unrelated pieces of data or logic
16. State (“Stickiness”) – Avoid tight and unwarranted associations between instances of data/logic and physical components
17. Topology Hotspots – Avoid associating physical components together in specific layouts and hard-wired connections unless warranted
18. Late Binding – Delay unavoidable dependencies till the last responsible juncture

When you put these principles together with the entities at each layer, it forms a simple and mutually reinforcing set of techniques, and the complete approach is what is "Dependency-Oriented Thinking". This is an extract from the document "Dependency-Oriented Thinking: Volume 1 - Analysis and Design":

There is a companion document on Governance and Management. Feel free to download both documents:

Dependency-Oriented Thinking: Volume 1 - Analysis and Design
Dependency-Oriented Thinking: Volume 2 - Governance and Management

Thursday, June 06, 2013

Red Hat's Competition Is From...Amazon

I was talking to a colleague about Red Hat yesterday, and it struck me that a new competitor has emerged that threatens Red Hat's business model in a fundamental way.

Red Hat has two main lines of business, Linux and JBoss. Yes, they also have a cloud platform called Redshift, but I'm guessing it's not yet of the scale of the other two.

Both Linux and JBoss are Open Source, so the revenues to Red Hat are through support subscriptions. Put very bluntly, Red Hat's business model is based on fear, rather like that of insurance companies. Customer organisations are generally afraid to run unsupported software in their data centres, so they will gladly pay the insurance premiums to ensure that someone stands behind the software they run.

But consider this subtle change in the model of reliability that comes about when we move to a cloud-based platform like Amazon. Reliability is achieved not so much by keeping servers running and getting them back online when there's a problem. The new model of reliability is to simply spin up new instances to replace failed servers. We can create images (AMIs) of our entire software stack, and spin up new instances either in response to increased volumes, or to replace instances that have died. This is actually done automatically, as part of the "elasticity" that cloud platforms deliver.

Mind you, Amazon itself suffers in adoption right now because of its own version of the fear factor.  The thought of placing one's business-critical data and processes in the cloud keeps many CIOs awake at night. But that fear is gradually easing as more and more organisations are seen to be migrating to that cloud platform with no adverse effects.

When Amazon becomes the norm for production infrastructure, the requirement for supported versions of operating systems may well reduce. The main difference between Red Hat Enterprise Linux and Centos (a RHEL clone) is that the former comes with paid support. If the reliability problem can be automatically addressed through elasticity, then Centos will do just as well.

That's why I think Red Hat needs to be afraid of Amazon.