Unchained — Architecture evaluation, governance, and domain boundaries
Context: Unchained operates in collaborative Bitcoin custody, where reliability,
data sensitivity, security posture, recoverability, and operational accountability are central
architecture concerns.
Architecture challenge: The organization needed clearer enterprise architecture
direction, a practical governance model, stronger visibility into data classification concerns,
and guidance while moving toward clearer domain boundaries and service responsibilities.
Design direction: Provide an initial enterprise architecture charter, introduce
lightweight governance practices, map architecture roles to current organizational reality,
review data classification concerns, recommend stronger domain-driven boundaries, and improve
reliability, recoverability, and observability direction.
Why this direction: A heavyweight enterprise architecture program would have
added friction, while informal architecture ownership would not provide enough accountability
for custody-related risk. A lightweight operating model created enough structure to support
decisions without slowing the organization down.
Outcome: Architecture evaluation produced practical governance direction,
role mapping, data classification review, reliability recommendations, observability guidance,
and domain-boundary recommendations.
First American Title — Integration architecture and transition planning
Context: First American Title had a hub-and-spoke message routing environment
supporting complex title insurance integrations and web service interactions from many acquisitions.
Architecture challenge: The existing integration approach needed to be understood,
documented, and translated into patterns that could support a more intentional service-oriented
direction to avoid the n-squared integration problem.
Design direction: Reverse-engineer the existing .NET hub-and-spoke message router,
identify integration patterns, document current-state behavior, recommend a transition path toward
an ESB-oriented model, and assist QA with a regression test harness for web service integrations.
Why this direction: Replacing integration infrastructure without understanding
the implicit patterns would increase delivery and regression risk. Capturing the current design
first allowed modernization recommendations to be grounded in actual behavior rather than
theoretical target-state diagrams, providing a smoother transition.
Outcome: The engagement produced integration pattern understanding, transition
plan recommendations, and testing direction to reduce risk during service integration changes.
SofTechnics / Mettler-Toledo — Enterprise retail modernization
Context: SofTechnics, a subsidiary of Mettler-Toledo, needed to replace
long-running retail applications that had accumulated decades of operational and architectural
complexity.
Architecture challenge: The modernization effort was requested by their clients
while preserving practical delivery paths for retail operations.
Design direction: Understanding their clients' needs for modernization led
to selling the organization on Enterprise Performance Management and Enterprise Decision Management
initiatives. This in turn drove the choice for a service-oriented infrastructure that could support
those initiatives, including business process management, business rules management, and workflow
management.
Why this direction: A direct rewrite of individual applications would not address
the larger enterprise coordination problem. A service-oriented architecture created reusable
capabilities, clearer integration boundaries, and a more adaptable foundation for future retail
decision and performance needs.
Outcome: The engagement established architecture direction for replacing legacy
retail applications with a more service-oriented enterprise platform foundation and a successful
pilot with Foodland.
Veterans Health Administration — National authentication and authorization architecture
Context: The Veterans Health Administration required authentication and
authorization integration across a large national heterogeneous healthcare environment.
Architecture challenge: The environment needed to support security, identity,
access control, interoperability, and enterprise authorization across diverse systems and
organizational boundaries.
Design direction: Lead design, prototype, and pilot work involving SSO, SAML,
XACML, RBAC, PKI, Kerberos, and related authentication and authorization architecture concerns.
Why this direction: A simple application-by-application access model would not
scale across a national healthcare environment. Standards-based identity and authorization patterns
were necessary to support interoperability, policy expression, security boundaries, and long-term
maintainability.
Outcome: The engagement produced design and prototype work for integrating
authentication and authorization systems across a large national healthcare context.
Segmint — Scalability, parallel processing, and real-time analytics architecture
Context: Segmint worked in banking and retail marketing analytics, where
throughput, data processing, cost, latency, and integration constraints affected product
direction and platform viability.
Architecture challenge: Existing Greenplum processing created scalability
constraints, while future business direction required faster, more flexible analytics capabilities.
Design direction: Use orchestration to parallelize Greenplum task processing,
then design and implement a low-cost real-time marketing analytics prototype capable of high
transaction volume and low response time without unnecessary cloud vendor lock-in.
Why this direction: Buying more hardware or rewriting the full platform would
have increased cost and risk. Removing the immediate constraint through parallel orchestration
created near-term throughput gains, while the prototype explored a more scalable future direction
including a new business channel.
Outcome: Processing throughput improved by 40% on the same hardware, and a
real-time analytics prototype demonstrated approximately 12k transactions per second with roughly
50ms response times at low monthly cloud cost.
VeDiscovery / Heureka — Parallel unstructured data processing architecture
Context: Legal data discovery required processing large volumes of unstructured
data within short windows, with court-driven timing pressure and significant operational demands.
Architecture challenge: The system needed substantially higher throughput without
depending on proportional hardware expansion.
Design direction: Design and implement a parallel unstructured data processing
architecture using distributed processing patterns and remotely deployable data discovery agents
with central final manual processing.
Why this direction: The workload was naturally parallelizable, and the business
constraint was processing time. A distributed processing model directly addressed the bottleneck
while preserving central review where human judgment and legal workflow required it.
Outcome: The architecture achieved more than 10x throughput on the same hardware
and supported large legal data loads within short processing windows.
Imagine Learning — Product prototype architecture and engineering transition
Context: Imagine Learning was developing a new flagship product and needed early
backend architecture and implementation support before the engineering team expanded.
Architecture challenge: The product needed enough architectural foundation to
support momentum, while avoiding overbuilding before the product and team shape were fully known.
Design direction: Lead prototype architecture, build the backend foundation,
and maintain design oversight while handing implementation responsibility to the growing
engineering team.
Why this direction: Early product architecture should create direction without
freezing every future decision. A prototype-backed foundation allowed the product to move while
preserving enough architectural consistency for team expansion.
Outcome: The engagement provided early product architecture, backend foundation
work, and a transition path from individual architecture leadership to team-owned implementation.
1M5 — Resilient, infrastructure-independent communications
Context: A long-running personal engineering project (roughly eight years):
a serverless peer-to-peer messaging system with no central infrastructure, cryptographic
identity, and an integrated value-transfer layer.
Architecture challenge: Support communication in environments where central
services, specific network paths, and identity assumptions cannot be trusted or may be
unavailable — without depending on any single transport or intermediary.
Design direction: Build on peer discovery and multiple interchangeable
transports (I2P, Tor, direct), hardware-backed OpenPGP identities, and graceful degradation as
conditions change. Bitcoin and Lightning were integrated as the value-transfer component.
Why this direction: Resilient communication cannot rely on a single network,
service, identity provider, or path. The architecture emphasized redundancy, decentralization,
and continued operation under denied or degraded network conditions.
Outcome: Working prototypes and a body of architecture and implementation work
(Java/Android/JavaFX) exploring infrastructure-independent communication, identity, and
value transfer. Open source.