The Legacy of Ivory Tower Architects

•November 12, 2014 • Leave a Comment

Much has been written, comments and discussed on the interaction of Ivory Tower Architectures and project teams.  Certain organisations I’ve worked for have unfortunately built departments of architectures who are so disconnected from the business, with obvious consequences – the business builds their own IT mini department/team.  Relevance offers an old blog posting with some useful thought on capturing architecture decisions on an agile project – particularly useful on multi-year projects.

Large documents are never kept up to date. Small, modular documents have at least a chance at being updated

ELK Stack – OSS Splunk?

•November 12, 2014 • Leave a Comment

ELK has been gaining a good amount of blog press recently.  Which leads to the obvious questions, of can ELK replace Splunk?  No an uncommon question given again the blog entries by various people on leveraging ELK.  More interesting is recent events, with an Splunk Exec moving to ElasticSearch, which should help to push ELK forwards.

OpenStack, Mesos and Docker – PaaS

•November 5, 2014 • 1 Comment

eBay’s 2014 posting on “Delivering eBay’s CI Solution with Apache Mesos” offer a hint of where we should possible be pushing with cloud computing:

Our new Mesos cluster is set up on top of our existing OpenStack deployment.

Our cluster is built on virtual servers in our OpenStack environment. Specifically, the cluster consists of virtual servers running Apache Zookeeper, Apache Mesos (masters and slaves), and Marathon services. This combination of services was chosen to provide a fault-tolerant and high-availability (HA) redundant solution. Our cluster consists of at least three servers running each of the above services.

The recent Velocity conference had an interesting session on Mesos and Docker.  Which leads to the concept that Docker on Mesos on OpenStack is an interesting PaaS.

Moving on from Scrum – Disciplined Agile Delivery

•November 5, 2014 • 1 Comment

I recently picked up a copy of Disciplined Agile Delivery (DAD).  DAD is a hybrid approach that extends Scrum with proven strategies from Agile Modeling (AM).  Anyone who has used Scrum on large enterprise projects will know what Scrum/XP doesn’t assist in the modeling, documentation and governance arena.  Page 4 offers a simple diagram showing the differences of Agile Development, Agile Delivery and Agility@Scale.

Over the years I’ve heard various debates about how much intellectual work can be done in a working day.  Page 31 offers a view that 5-6hrs a day is the norm for achieving high-quality intellectual work.  Often overlooked, “Visualize Workflow” often aids teams in understanding blockers, and utilization.

Chapter 4 provide insight into roles, rights and responsibilities which marries back to the Terminology Tar Pit on page 43.  Roles and responsibilities are often overlooked on the forming of a new team, with the implicit expectation that people will know what role they need to fill based on history.  Architecture Owner, page 76, should provide some clarity in an often contentious title.

If you happen to be on a a graphically split team, then DAD may not be the best approach to follow – page 4/87.  Page 99 offers some further thoughts to geographically distributed/dispersed teams.

Funding, always and interesting project area, is discussed on page 126, coupled with some views on estimating.

Have to agree with the “Just do it” comment on page 133 – Jumping into Construction.  A classic anti-pattern which is sure to guarantee the wrong architecture, poor quality of code, amongst other issues.

Choosing the right type of model is often not thought though on a new project.  Specifically because old patterns and methods and followed without new thinking.  Page 155 compares a number of modeling options.  UI specifications have become almost a norm in recent years with the influence of User Experience though process on projects, however UML and flow charts still have their place.

An often debated subject is choosing a strategy for Non-functional Requirements (NFRs).  Page 170 offers three basic strategies.  I agree with the advice on page 171, acceptance criteria.

Good list of architectural modeling views in table 9.2, page 184.  Hopefully, the project you are on doesn’t follow the no modelling view (page 180)

Often debated by the stakeholders funding of a project, estimation is unfortunately contentious.  Hopefully page 218 can provide some assistance.

Construction phase and iteration overview diagram on page 281 offers a great view of what should be done, and also what is often missed :(  Patterns and anti-patterns offer a great read as well (284).  How many times have you see people spread over more than one project in a week – “task-switching between projects takes time and is a huge source of waste” (page 285)

Page 310 should hopefully offer the construction crew ideas around leveraging their working day.  Of particular note is the “stabilize build” – how many times have you see the build broken as people leave the office at the end of the day? :(

Transition anti-patterns (page 429).  How many times have you started a project, and even after 3+mths, you still don’t have a production like environment for integration, acceptance and deployment testing (anti-pattern 101)

Potential metrics for agile projects (page 469) includes the usual suspects, but also offers a few that are often not captured – e.g. agile of work item.

Great to see Continuous Delivery (CD), BDD, TDD and ATDD mentioned throughout the book.

Final food for thought:

  • Stop the rush into construction.  Model
  • Prove the architecture early
  • Read the book :)






Hadoop Tutorials

•October 23, 2014 • Leave a Comment

Hortonworks seems to have done a good job on offering Hadoop tutorials, leveraging a Sandbox.  In particular, they offer a real-time event stream with Apache Kafka which is then persisted into HBase and Hive using Storm Bolt.  Food for thought

21st Century Pricing Engines

•October 22, 2014 • Leave a Comment

In todays markets, there are a number of drives that influence the buy vs build of a pricing engine irrespective of asset class.  Those drives probably include the following:

  • Consistent pricing
  • Minimising the number of trade away %
  • Ability to on-boarding clients in a timely manner
  • High availability, low latency of both price construction, and price delivery

This leads to a number of requirements which i suspect maybe mandatory in certain organisations:

  • Liquidity steam per user (not client) sourced from a liquidity pool – historical 3-5 tier pricing probably isn’t good enough these days
  • High availability – consistent pricing from multi data centres
  • Injection of CIV to influence price construction
  • Ingestion of order and traded away data to improve the core price generation
  • Parameter driven configuration
  • Influenced by the latency from end to end – slow/fast consuming clients

Which then leads to the questions, do you build or buy an off the shelf product.


Definition of Ready

•October 21, 2014 • Leave a Comment

You’ll always hear about the Definition of Done (DOD) from agile teams.  However, what is not so often discussed is Definition of Ready (DOR) – sometimes referred to as DevReady in various organisations. Fabrique’s SXSW 2013 slide deck (53) offers a view of DOR.   The Agile Alliance crystallises why DOR is important:

Avoids beginning work on features that do not have clearly defined completion criteria, which usually translates into costly back-and-forth discussion or rework

Churn during iteration due to imprecise requirements is often the by-product of not having a strict DOR.


Get every new post delivered to your Inbox.

Join 665 other followers