My new blog is at http://looselycoupledthinking.com and has two formats:

• A Noteblog
• Traditional long-form blog

Most of my Twitter posts are available on my Link Blog. 

 Also posted to my new "blog-in-progress" here

Someone asked me for a quick email on apps, services and components. Feedback and flames welcome.

An app is a logical grouping of components and services to perform a business objective. 

-        Logical because the components may not all be owned by or located within the organization that built the app

-        An app is built to change by swapping and versioning the services and components that make it up

-        See below for suggested definitions of component and service

Services are lightweight, loosely coupled black boxes of reusable functionality that are accessed via a standardized interface.

-        Services are built to last

-        Once deployed, a service's contract should not be changed – it is usually better to version a contract than completely replace it (especially if your service supports multiple consumers)

-        Services are not necessarily web services – a web service is merely one way in which a service can be implemented

-        Services can be composed into larger constructs referred to as Apps. 

-        Fine-grained services result in greater reuse but may be more difficult to design

• Fine-grained services support a single, simple piece of functionality
• Fine-grained services typically result from a bottom-up approach

-        Coarse-grained services typically support higher/more complex functionality   

• Coarse-grained services are typically composed of two or more fine-grained services
• Coarse -grained services typically result from a top-down approach

Components are similar to services are more tightly coupled to a specific platform or technology in terms of their implementation.

-        Components are typically built to last but may expose parameters or configurations that affect its behavior

-        Components have very specific requirements for usage – typically in the form of libraries, dlls or databases (e.g. stored procedures)

-        Components may yield better performance or throughput due to their tightly coupled nature

-        Versioning components tends to be more difficult due to their tightly coupled nature

-        Like services, components can be fine-grained or coarse-grained

-        Components can be combined with services into larger constructs referred to as Apps

Note: I'm in the process of moving to an awesome new blogging platform by the insanely great Dave Winer. If you blog I highly encourage you to look into Fargo.  My new blog can be found at http://looselycoupledthinking.com.

I'm hearing the term "modern architecture" used quite a bit but haven't seen much clarification about what it actually means.  Here are some principles and capabilities that I would expect to see in "modern architecture":

1. Cloud first
2. Loosely coupled, distributed services
3. Support Postel's Law
4. Distributed storage and caching
5. Weak/Eventual Consistency (CAP) - committed reads
6. REST APIs where appropriate
7. Scale out, not up
8. Stateless
9. No apparent downtime
10. No biz logic in sprocs (prefer no sprocs at all)
11. No ref integrity in db - enforce in service/app if needed
12. No distributed txns
13. Simple data abstractions for data access
14. Multiple service versions in production 
15. Active-active failovers across DCs where appropriate
16. No singletons, at least 4 instances of a service running in prod (2 per DC)
17. Consistent approach to monitoring/logging/SLE threshold compliance•
18. Real-time access to service health/activity
19. Design for/expect failure - degrade gracefully
20. Test in production
21. No reporting from txn data - keep OLTP and OLAP separate
22. Asynchronous user experiences (no blocking)
23. Avoid designing for a single device or form factor (user-scalable=0 is evil)

I'll plan to drill into more detail on several of these topics over the next couple of posts.

What do you think is missing from this list?  What shouldn't be in this list?

 Updates:

• Mike Kavis suggested via FB that "Modern solutions have a combo of SQL, nosql, cache, CDN, and many other data and storage technologies under the hood".  I'd interpret this as: Data stores should be abstracted without regard to where/how they should be accessed.  The abstraction hands off to a more granular access component/service with specific awareness to location/access requirements/etc.

BTW I'm currently reading Mike's new book.  I'm liking what I've read thus far - I'll post a full review when I've finally finished it.    

Message reliability focuses on the delivery of messages. Message reliability means a message needs to be delivered at least once with possible duplicates or at most once with no duplicates.  Reliability also dictates whether messages must be delivered in the same order they were sent or can be delivered out of order.

Message durability focuses on the management of messages.  Message durability dictates whether a message can be simply kept in-memory or if it must be saved to persisted storage to avoid message loss (in-memory messages are lost during system, network or power failures).  Durable messaging also enables operations to resolve issues in an much easier manner than relying solely upon reliable messaging.  When a durable messaging solution experiences an exception or outage it is much easier to determine the state of the transactions and restore/replay messages from a known state without losing any messages.

Now you know.

Sorry about the lack of embedded links below - I blogged this on a tablet from notepad. Can anyone recommend a good mobile blogging app?

I spent a few minutes this morning reviewing the OASIS MQTT spec (see https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt ). MQTT hopes to become the standard for communication on the "Internet of things". (I use the term "Internet" instead of "web" here because it uses ip, not http. ) Given the long legacy of proprietary sensor networks (medical devices, vendor managed inventory sensors, RFID scanners, etc) it's good to see some effort to standardize things and make it easier for multi-deviceintegration. The spec itself is pub/sub based (thank goodness). There isn't any concept of XML or REST here - devices are typically very lightweight with limited resources (think bits over ip). MQTT could be "REST-like" in terms of identifying/requesting resources (not via URIs apparently). The qos semantics are fairly straightforward but the spec doesn't provide any guidance on ensuring an implementation is aligned with semantics (out of scope, apparently). Message durability doesn't seem to be addressed. It's early though and these areas might be addressed as the TC evolves the spec. Regardless of how things turn out it's still good to see standards emerge in this space.

Related: Phil Windley (http://www.windley.com/) is doing some interesting stuff on his Kynetx platform (http://www.kynetx.com) related to the "Internet of things" - check out SquareTag (https://squaretag.com/ ). SquareTag obviously isn't MQTT (uses QR Codes) but it does enable the "Internet of things" concept in a highly relatable and useful way.

Update: just learned of an open source implementation of MQTT called Mosquitto

A while ago I was asked to do a simple comparison between Service Bus for Windows Server (SBWS) and Azure Service Bus (ASB) so I thought I’d share this with you all.   Most of this stuff is probably obvious.  A more detailed comparison is available here and is well worth a read.

Installation and support

• ASB: Since ASB is a cloud-based service there is no software to install and support is provided by Microsoft. OS and application patching and updating is also handled by Microsoft. Storage is provided by and managed by Microsoft. Backups and business continuity of ASB itself is managed by Microsoft.
• SBWS: SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.

Message Relays

• ASB: ASB’s relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging.
• SBWS: At the time of this writing SBWS did not support relayed messaging.

Security

• ASB: Solutions deployed in Azure using ASB can make use of Azure’s security token service known as ACS (Access Control Service). ACS is a cloud-based authentication and authorization service that integrates with standards-based identity providers such as enterprise Active Directory, and web identities like Windows Live ID, Google, Yahoo!, and Facebook.
• SBWS: Solutions deployed on-premises using SBWS can make use of the Service Bus Security Token Service (SBSTS) which is fully integrated with the Windows security model. SBSTS can issue self-signed Simple Web Tokens (SWTs) using Windows identities.

Quotas/runtime settings

• ASB: Options regarding message and queue sizes are fixed due to the multi-tenant nature of ASB.  ASB Queue/Topic sizes can be up to 5 GB.  Messages can be up to 256K.  See here for specifics on ASB quotas.
• SBWS: SBWS provides much greater freedom for configuring runtime settings and message and queue sizes.   SBWS Queue/Topic sizes can be up to 10 GB.  Messages can be up to 50MB.    See here for specifics on SBWS quotas.

Network latency

• ASB: Network and security latencies may impact performance, especially when moving messages from on-premises to cloud or cloud to on-premises. Throughput could also be impacted by unexpected spikes in unrelated internet traffic.
• SBWS: Administrators have much more control over their own network’s traffic and routing, thereby enabling more efficient bandwidth usage and throughput.

Addressing schemas

• ASB: ASB Namespaces are fixed – all endpoints have a Service Bus postfix added to the URL to ensure uniqueness.
• SBWS: SBWS uses fully qualified domain names (FQDN) or a mapped DNS entry to represent service namespaces.

Instances

• ASB: In ASB there is only one "instance" of the service available and it is managed by Microsoft.
• SBWS: With SBWS it is possible to have several on-premises SBWS servers via self-hosted servers or third-party providers.

Cloud taxonomies consist of a Service model and a Hosting Model.

• Service model - There are three service models: SAAS, IAAS and PAAS. 
• Everything else is a scenario that falls into one of these three models (e.g. *AAS)
• Hosting model - There are two hosting models: Public and Private.
• Virtualization is an implementation choice within one of these models.

Your feedback and flames are welcome…

Many people who “design UX” seem to spend the bulk of their time focusing on the screen layout, controls and behavior of various elements on the screen. Many weeks can be spent conducting user studies, analyzing feedback and reviewing various fonts and color schemes in an attempt to provide the most aesthetically pleasing user experience.  These are important things to focus on but something obvious usually goes missing – what about the data?  Where is the data coming from?  How must the data be transformed or manipulated prior to displaying it to the user?  These critical questions are frequently an afterthought as design engineers focus instead upon the look and feel of a given screen.  Focusing on the look, layout and behavior of individual controls on the screen is UI, not UX.  UX should require that designers consider potential latencies due to data retrieval, security and other background processes that impact the overall performance of the user experience.  A beautifully designed screen that performs poorly always results in a poor user experience. 

So how should one design a great UX?  I’m not a UX expert but I’d suggest you start by understanding the data that the screen is to display or work with.  List all of the fields or data elements that the screen must display or accept from the user.  Try to answer the following questions:

• Where is the data coming from?
• How long will it take to retrieve the data to display to the user?
• What relationships (if any) are inherent in the data to be displayed or processed?
• Is the data in a format that is presentable to the user or must it be transformed?
• For data entry try to invoke the validation rules as close as possible the actual data entry experience
• Is it possible to retrieve the data proactively via a background process?
• How can we “distract” the user while their data is being retrieved/transformed/validated or otherwise processed?

Avoid blocking, especially if the data must be retrieved or processed by a slow/remote network location or an underperforming back end system.  Users have become accustomed to asynchronous experiences - blocking users with an hourglass, spinner or some other form of “dancing monkey” is insufficient. 

Design engineers should work closely with architects or developers to become intimately familiar with the data and its associated service level expectations (SLEs).  Understanding data behaviors can help design engineers avoid designing a Ferrari that performs like a Yugo.

Calling a meeting:

• Always specify three things in the invite:
• Objective
• Agenda (ideally timeboxing each agenda item)
• Last agenda item is always summing up/next steps
• Expected Outcomes
• Failure to include these items means:
• people you invite should consider themselves optional attendees
• you cannot hold people accountable that choose to skip your meeting
• Being an optional attendee to any meeting means you can skip it
• Always ask invitees to suggest an alternate date/time if they cannot attend
• If an invitee rejects your invite without suggesting an alternate date/time they are not interested in attending and will reject future invitations, even if you reschedule the meeting
• All this stuff makes calling a meeting difficult – forcing you to think about whether you really need it

Showing Up:

• Early is On Time
• On Time is Late
• Late is Unacceptable
• My employer used to lock the meeting room door when the meeting started. Late attendees would have to knock to gain entry (and were usually ignored)

Leaving the meeting:

• If the meeting starts running over attendees can get up and leave, regardless of what’s happening in the meeting
• Keep your laptop closed unless you’re using it to take notes or doing something related to the meeting

Enjoy.

Windows logo key+spacebar Switch input language and keyboard layout
Windows logo key+O Locks device orientation
Windows logo key+Y Temporarily peeks at the desktop
Windows logo key+V Cycles through toasts
Windows logo key+Shift+V Cycles through toasts in reverse order
Windows logo key+Enter Launches Narrator
Windows logo key+PgUp Moves Metro style apps to the monitor on the left
Windows logo key+PgDown Moves Metro style apps to the monitor on the right
Windows logo key+Shift+. Moves the gutter to the left (snaps an application)
Windows logo key+. Moves the gutter to the right (snaps an application)
Windows logo key+C Opens Charms bar
Windows logo key+I Opens Settings charm
Windows logo key+K Opens Connect charm
Windows logo key+H Opens Share charm
Windows logo key+Q Opens Search pane
Windows logo key+W Opens Settings Search app
Windows logo key+F Opens File Search app
Windows logo key+Tab Cycles through Metro style apps
Windows logo key+Shift+Tab Cycles through Metro style apps in reverse order
Windows logo key+Ctrl+Tab Cycles through Metro style apps and snaps them as they are cycled
Windows logo key+Z Opens App Bar