Understanding the Apple Post-PC Era (iPad 2)

With all the hype surrounding Apple’s latest products and business model it is hard to see beyond the spiel. I’ll try to clear some missed conceptions about the novelty of this approach to technical consumerism.

So what do we have?

• We have a great device and an ok OS taking the most of touch technology. It is ahead of competition in terms of what we may call, UI experience.
• We also have lot's of content taking the most of what the device can offer.
• We have financial conditions imposed by the builder to any business that wants to get into this market

So in sum we have the the Console Business Model transposed to the mobile computing environment.

Apple had the intelligence to understand that the success of the Tablet can only be won trough Content. If there is no content, there is no success and no competition. To have content we need content producers. To have content producers we need not only to convince them that the technology is great, but that it is better for the user while opening new doors for production and sales.

Let's face it, Google attempts don’t do anything about this. It is useful, but is geeky. It is well seen by the public as long as we don’t have to pay much for it. Otherwise is not worth it.

One company that we have been neglecting in this race is Microsoft. When it comes to the Console business model Microsoft can leverage on the experience gathered by XBOX360 business lines and its enterprise presence to build something cool yet accessible. If they can pull of a Tablet OS without Windows but with Windows. Balancing together Media Center experience, XBOX360 experience and the PC experience in a model that is closed yet more open then the competition it just might turn tables all around.

Challenges

The challenge of bringing the Console model to the Personal Computing environment is IMHO the following.

- Consoles usually don't have a high rate of hardware updates. This allows the system to become cheaper in time as well as increasing profit due to lower production costs. This in turn makes the system more accessible to a wider set of audiences and with that comes market growth and presence. The Apple model is precisely the contrary. Every year a new update, making ones expensive device obsolete in 3 years.

- Content on a Console is usually priced higher then on a PC. By requiring product prices in its platform to be equal or lower then any other platform, Apple forcing the a rise in prices across the board. This is good for Apple, but bad for customers and the competition. I'm not really sure if this is good for content producers either in the long run.

- Consoles usage is quite specific and limited. So they don't have to put up with increased functional diversity and associated costs.

The point that Steve Jobs makes is such that people do not want a Personal Computer anymore. They want a blend between devices and liberal art's and humanities in an enticing way. For this, the customer does not mind to pay premium even if the choice is somewhat limited.

His point is valid, but it is not by all means a tautology. He is quite right in stating that people don’t want hardware anymore, they want something more useful. Yet it is not they don’t want a PC, in fact they still want an relatively open personal computing environment to share, consume and produce content.

For that matter as in Consoles, content and innovation is paramount to succeed. We have examples from Nintendo, XBOX360 and PS3, we just need to bring that experience to the PC balancing the open and close models together into a single platform.

DDD, Facts & Figures: Core Conceptual Foundations

Design, in and of itself, is a complex cognitive task bringing to bear a host of knowledge types and sources and a myriad of problem solving skills
[Dasgupta, 1991]. A number of researchers have shown that complexity is an essential property of design activities in general, due in part to the inevitably incomplete formulation of the problem, and in part to our inability to cope simultaneously with all of the constraints of a given problem (our bounded rationality [Simon, 1982]).

To help us, during the course of last year, the DDD community introduced new design patterns such as Domain Events, CQRS, Event Sourcing and Sagas. Albeit not new, the application’s of these patterns in DDD is nevertheless refreshing.

After reading a lot about these patterns I was able to understand each pattern individually within the scope of DDD. Yet when we get everything together, I always felt that a peace of the puzzle is missing, without which we may fall into a design “cliff” back into muddy waters with our designs.

In search for what was missing in my brain to fully understand these patterns I came up with just another formulation for domain modeling and design that you might appreciate. This is not the accepted DDD formulation, still it is about DDD.

This will the the first post, of my first attempt in explaining what I’ve learned in the latest in the DDD forum and intertwined my own perception of domain modeling and design.

Facts & Figures

I mostly build business software solutions in the Insurance context. So in my attempt to find the core artifacts of domain modeling I started observing what is required for domain experts to make them.

In turns out that my observable experience business decisions are made after considering facts and calculated figures in context. Decisions lead to other facts and figures and so on. 

 

So why aren’t we using facts and figures as core archetypes in our designs?

To find the answer to these questions we need to establish a common undetstanding of the terms above. I believe that this understanding all it is needed to make effective domain models across all sort of programming paradigms.

Decision: A determination arrived at after consideration.

Example: Buy my self an iPad in the online Apple Store

Consideration of what? Consideration of things that the business believes as facts. The outcome of this process is a set constraints over decisions.

Constraint:  The state of being checked, restricted, or compelled to avoid or perform some action.

Example: If Nuno has no valid credit card he cannot buy an iPad in the online Apple Store.

So considering that fact that Nuno has no valid credit card, he cannot buy the iPad on the online Apple Store.

Fact: A thing done or performed. A provable concept.

Example: Nuno bought an iPad in the online Apple Store.

Figure: A written or printed symbol representing something other than a letter, especially a number. Figures usually vary in precision. When a figure is provable, is often referred as a fact.

Example: Nuno bought 1 iPad in the online Apple Store.

In my next article I’ll expand a bit more about these concepts. Until then, and if you know about the DDD patterns enumerated above, consider that events are with we may call axioms …

CQRS in a sentence

The essential purpose of CQRS is to bridge the gap between the client side view of the domain and the Domain Model implemented in the server side.

The structure itself is useful when we need to simultaneously convey multiple Entities from the Domain Model to multiple contexts with a different arrangement.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Antoine de Saint-Exupery

French writer (1900 - 1944)

Why the MVC perspective may be of relevance to CQRS?

I got a very interesting observation regarding the last post from a person that I follow closely. His technical teachings help so many, that I guess if he comes with such an observation it must be one that a lot of people will.

The observation was that albeit both patterns are structurally comparable, the contexts where each are applied are so different in nature that similarities may be irrelevant.

As naive as it may sound here is why it may not be such case.

Although the term "structure" was used, the scope of this term is basically one of diagram structure. What may be more relevant is:

• The way each pattern distributes responsibility amongst the concepts is the same.
• The information flows amongst concepts in the same way.

In other words, the top level algorithm is the same.

If algorithms are the same, the probability of problems solved by each ending up being of the same kind is quite high. In the end of the day we are building software and few things can be more asynchronous and prone to errors then a person or group of persons interacting with the same UI.

Considering how different the play field of each pattern is, probably we are facing a singularity, a constant solution in systems design that solves a particular set of top level problems across a wide set of technical contexts. This whether the challenges is one of building an UI or a distributed system that needs to be highly scalable. This usually rises some opportunities of simplification across the board.

Within the Domain Controller take for instance the concept of Saga. The Saga pattern is a solution applicable when we identify multiple inputs that need to be treated together has a unit (all or nothing). Yet we cannot put all those inputs into a single transaction (think a complex client/server interaction with multiple calls). The Saga gives the client the illusion that is dealing with one single domain concept yet it is orchestrating several domain objects (enforcing  invariants etc). We can imagine a very large Order built over time common in procurement processes. After the transaction ends, the Saga is disposed yet the Order remains.

A similar situation we have in the UI space when dealing with editing and presenting complex sets of information that need to be treated has a unit(say a complex task such as user registration or payment). The amount of information to be collected is such that to simplify, we split the information along several screens, each capturing only a part of the information (Wizard). This problem is solved with MVC by introducing the concept of Tool. A more sophisticated tool is one of Composite Tool hence we come to the reasoning around Composite UIs (BCs etc). When the Wizard is submitted all the data collected is sent to the domain model and the Tool is then disposed.

Quite often the subject of task based UIs come along with CQRS and scalability. Generally speaking my understanding is that by aligning the design of the UI with the way information flows across CQRS participants (and vice versa) we get a system that is far more scalable while keeping the implementation recurrent and simple then we could otherwise. 

Currently I'm not at the level of decision making where were I can apply this. So to me this comparison may bring some light in explaining why such alignment may be so elegantly effective.

If everything above fails in explaining why it may be of relevance then at least it will not fail in bringing awareness on how similar both patterns are. As such we can only wonder if experiences (successes and failures) on building solutions and tools around MVC can be selectively transposed  to the environments where CQRS is of value (avoiding the pitfalls of some approaches and capitalize on success of others).

Bringing an MVC perspective to CQRS.

This article makes the point that the MVC and CQRS patterns are very similar. My hope is that with this "new" understating new development tools bringing the two patterns together can be developed to facilitate our programmers lives.

To compare MVC with CQRS we need undress the later of all technical details regarding its implementation and bring out the focus on how information flows between each of its components and its relationships.

Comparing MVC and CQRS Pattern Structures

If you haven't read the article "Clarified CQRS" from Udi Dahan along with Greg Young posts please do. Both have discovered this pattern and they are the authoritative source of anything regarding CQRS. Having said this, for the sake of this comparison I took the liberty of changing the names of certain things of CQRS:

• The Read Part of CQRS is mapped to Domain View in the diagram above.
• The Command Bus is mapped to the Domain Controller. Here is where Commands are mapped to the calls to domain objects as well as Sagas amongst other things.
• The Domain Model, well is the Domain Model.

One particular leg that probably we are not used to see discussed with CQRS is the one connecting the Domain View with the Domain Model. This leg simply reflects the scenario where the view accesses domain services or the domain model is mapped to the view model using for instance a ORM.

We also have two Event legs. One coming out of the Domain Controller and the another coming from the Domain Model:

• The one coming out from the Domain Controller reflects the scenario where the Command Bus is responsible for publishing domain events as a result of performing an action against a domain object (Udi way I guess);
• The one coming out the Domain Object reflects the scenario when the Repository publishes such events (Greg way I guess).

Choosing one or another depends on what object assures that performing the action and publishing the events occurs in a single transaction.

The MVC is similar to CQRS in the sense that we have two ways of getting the result of performing the operation against the domain model. In certain scenarios information is served by the controller, in others us served by the domain model. The first option can be asynchronous or synchronous but is usually synchronous.

Combining MVC with CQRS

The above combination results from scenarios where the Model in MVC is a façade as defined in [GoF]. In CQRS Controller and its View provide such façade through Command and Query objects.

The above combination results from merging the View in MVC with the View in CQRS. This can be scenario where the views of each application register with the domain model or controller. Common usages can be found in some Games with Web Interfaces that pull notifications from the server and update its interface

Concluding

There are for certain many other ways that we can compose both patterns. Especially when get into composite user interfaces as defined by the discoverer of MVC pattern, Dr. Trygve Reenskaug, in his article "MVC. It's Past and Present".

In retrospect, the similarities between both patterns maybe not be such a surprise. Amongst other things, both target solving the structural impedance mismatch between accessing information and changing information when using a domain model. Albeit each dealing with technical contexts that are quite different.

Questions and comments are most welcome.

Teorema de Brewer (CAP)

O teorema CAP descoberto por Eric Brewer, foi apresentado pela primeira vês a 19 de Julho de 2000, quarta-feira, no simpósio da ACM intitulado "Principles of Distributed Computing" .

Este teorema resultou de um extenso trabalho de observação do comportamento dos sistemas da Inktomi e veio a revolucionar a arquitectura de sistemas de grande escala.

Nomeadamente a arquitectura dos sistemas da Amazon, eBay e Twitter entre muitas outras.

Mas afinal o que é o teorema de Brewer?

Brewer identificou 3 requisitos sistémicos fundamentais que se influenciam mutuamente no desenho e instalação de sistemas distribuídos.

Estes são: Consistência, Disponibilidade e Tolerância a Quebras - "Consistency, Availability, Partition Tolerance" ou CAP.

Consistência

Um sistema é consistente se não gerar resultados contraditórios entre si tendo como base a lógica de negócio implementada.

Por exemplo, partindo do princípio que aplicação foi testada e a lógica implementada está correcta um sistema consistente garante que:

• o mesmo livro nunca será endereçado para dois clientes distintos em simultâneo;
• um contrato de seguros não será realizado com um cliente com elevado grau de sinistralidade;
• um cliente nunca pagará mais ou menos do que o valor em factura;
• nunca serão dadas ordens de pagamento em duplicado;
• um cliente não pode pagar com VISA um valor assima do seu plafond;
• entre muitos outros cenários e regras que poderíamos enumerar.

Disponibilidade

Um sistema está disponível sempre que dá resposta ás solicitações dos seus utilizadores, e indisponível caso contrário.

Por exemplo, quando se submete um contracto de seguros quer-se que o sistema responda e que não dê uma mensagem do tipo "time-out" ou "sistema indisponível".

Um sistema pode ser mais ou menos disponível num período de tempo. No entanto num determinado momento T está ou não está disponível.

Tolerância a Quebras

Uma quebra no sistema é a falha de um componente ou ligação entre componentes da solução.

Por exemplo se a nossa aplicação está distribuída por múltiplos "tiers" ou nós numa rede informática, uma quebra pode ser o servidor desligar-se, o router bloquear ou um cabo de rede partir-se e deixar de funcionar.

Como é óbvio nesta configuração a probabilidade haver quebras nas ligações entre os componentes da solução é elevada quando comparada com uma solução de máquina única.

Um sistema é tolerante a quebras se nada menos do que a falha total da rede formada pelos seus componentes o leve a deixar de funcionar correctamente.

A Revelação de Brewer

A revelação de Brewer é que não é possível que um sistema informático preencha estes 3 requisitos em simultâneo. Mante-los e escalando o sistema ao mesmo tempo por forma a dar conta do aumento de actividade, torna-se cada vês mais dispendioso atingindo um ponto de impossibilidade técnica com impacto directo na disponibilidade.

Quantos de nós em grandes empresas já ouvimos dizer, o sistema está lento, está indisponível ou "está em baixo" durante minutos e em alguns casos horas?

Acabo assim com estas duas questões. 10 anos depois ...

• É este teorema significativo para os departamentos de IT das grandes empresas em PT, nomeadamente na forma como o negócio é gerido electrónicamente?
• Qual é o seu significado técnico para os departamentos de IT de hoje em PT?

Assim começa este blog

Olá, chamo-me Nuno Lopes e sejam bem vindos a este Blog.

A minha carreira conta com mais de 20 anos de experiência no desenvolvimento de software empresarial. No entanto em boa verdade quanto mais mais aprendo mais tenho consciência que sou perito de coisa nenhuma.

Serve assim isto como mote para criar este espaço de reflexão e partilha daquilo que aprendi e do que me falta ainda aprender sobre o que de melhor se faz pelo mundo fora na área do desenvolvimento de software empresarial.

Conto assim com os vossos comentários.

Bem ajam,

Nuno Lopes