At 27Global, we build software for clients across a lot of industries and each project brings its own tech stack, its own quirks, and its own definition of "done." But there's one challenge that shows up every time, no matter the domain: how do you keep architecture work visible, measurable, and consistent across a whole consulting organization?
The answer we've landed on is AppFaktors, and the three tools we lean on most are Taskboard Playbooks, Scorecards, and Policies. Each one solves a different piece of the governance puzzle. Together, they go a long way toward turning "how are we doing?" from a myster into an answer.
Playbooks: Your Architecture TODO List, Minus the Guesswork
A Playbook in AppFaktors is essentially a structured task list — a set of Cards organized into Lists — that gets applied to an Architecture record and becomes its Taskboard. Think of it as the pre-flight checklist your team works through from project kickoff to client handoff.
Our 27G New Project Engineering Playbook covers five phases:
- Phase 1 — Definition: Capture requirements, assess current state (if any), pick a tech stack, define branch and release strategy, lock down security posture.
- Phase 2 — Design: Build out the domain model, system context and detail views, deployment diagrams. Scaffold repos and infrastructure, configure CI/CD, set up monitoring and secrets management.
- Phase 3 — Build: Code reviews, sprint management, test coverage, DORA metrics. The ongoing work that actually ships software.
- Phase 4 — Production Readiness: Load testing, pen testing, final documentation polish.
- Phase 5 — Client Handoff / Closeout: Client review sessions, final documentation delivery, technical training.
Each task has a description that tells the Architect and Cloud Engineer exactly what "done" means for that card. For example, task 1.0 — "Create AppFaktors Architecture Record" — isn't just "set up the project." It specifies that the record must be established before any design work begins and serves as the canonical reference for everything that follows. Task 2.6 — "Present Proposed Design to Peers" — isn't optional either; it's a mandatory design review with the Architecture team before a single line of build code is written.
Once the Playbook is applied to an Architecture, the first thing you do is assign due dates to every card. This converts a generic template into a project-specific timeline. From there, it's a living board — Architects and Cloud Engineers update cards as they work, and everyone (including the client) gets a clear picture of where things stand.
The practical payoff is that you stop relying on individual memory or tribal knowledge. A new architect on the project can look at the board and immediately understand what's been done, what's in progress, and what's next. That's not nothing when you're spinning up four or five projects at once across different teams.
Scorecards: Putting a Number on "Is This Architecture Any Good?"
Here's the uncomfortable truth about architecture reviews: a lot of them come down to vibes. "This looks pretty solid." "I think we're in good shape." Those assessments aren't useless — experienced people have good instincts — but they're hard to track over time, hard to compare across projects, and nearly impossible to hand to a client with any confidence.
Scorecards fix that by running automated checks against your architecture and producing an actual score. Our Application Scorecard spans 14 categories and 76 individual checks, each weighted equally and evaluated against your live architecture record. The result is a percentage score per category and an overall aggregate — something you can actually point to in a project review.
The checks cover the full surface area of an architecture: domain modeling, requirements, diagramming, deployment, Infrastructure as Code, pull requests, documentation, and more. Each one is specific enough to be meaningful. Take the Architecture Views category — it doesn't just ask "do diagrams exist?" It verifies that every logical system defined in the System Context View has a corresponding System Detail diagram with at least 3 components and 2 connectors. A box with an arrow pointing at a cloud doesn't pass. That specificity is the point.
Or consider Key Decisions. The check doesn't ask whether you've made architecture decisions — of course you have. It asks whether they're documented in proper ADR format: context, options considered, chosen option, trade-off analysis, and an assigned owner. This is the category where teams most often have a gap between "we made decisions" and "we documented them in a way that survives a personnel change six months from now."
Once you run a Scorecard, AppFaktors can generate Action Items for anything that didn't pass — so the score isn't just a grade, it's the start of a remediation list. That matters because the goal isn't to celebrate a good score; it's to surface the gaps early enough to do something about them. Running the scorecard mid-project and seeing the Domain Model category sitting at 20% is uncomfortable, but it's a conversation you want to have in week four, not week twelve.
The deeper value is consistency across the organization. Every project, every team, measured the same way. Over time, patterns emerge — categories that consistently lag, check types that signal downstream problems, project profiles that predict risk. That's the kind of organizational intelligence that's genuinely hard to build any other way.
Policies: Automated Best Practices That Don't Forget
If a Scorecard is a snapshot, a Policy is a standing rule. Policies are automated validations that run against your architecture and tell you whether it meets a defined standard — not once, but continuously.
AppFaktors supports multiple out-of-the-box policy standards (NIST, for example), and you can define custom ones. Each Policy contains one or more Policy Objectives, and each Objective contains Controls and Rules.
- Controls validate characteristics that live outside AppFaktors — think GitHub branch protections, Azure configuration, things like that.
- Rules validate characteristics that are part of the Architecture definition in AppFaktors, using a JavaScript (Google CEL) function that interacts with the
modelInfoobject.
In practice, this means you can codify the things that would otherwise live in someone's mental checklist: "Every architecture must have an SDLC policy applied." "Every architecture in the healthcare vertical must have a HIPAA compliance requirement." "Every production deployment must have a security policy linked."
For consulting, this is particularly useful because the standards aren't just internal hygiene — they track industry-specific needs. A project in finance needs different compliance requirements than a project in logistics. Policies let you define those constraints formally and verify them automatically, rather than hoping someone on the review remembers to ask.
The Scorecard checks whether policies exist and are applied. The Policies themselves check whether your architecture satisfies them. Both are necessary. "We have a security policy" and "our architecture passes the security policy" are different statements.
How They Fit Together
The relationship between the three tools follows a natural project arc:
The Playbook gets you started. Day one of the project, it's your task list. It tells the team what to do and in what order. The Architect and Cloud Engineer work through the cards, update due dates, and use it to stay coordinated with each other and with the PM.
The Scorecard measures where you are. You can run it mid-project to see which gaps need attention before they become handoff problems. Ran it on a new project and the Domain Model category is at 20%? That's a conversation to have now, not in week 10.
Policies enforce the ongoing standards. Once applied to an architecture, they run continuously and produce findings whenever something drifts out of compliance. A developer merges a PR without a reviewer? A policy catches it. An environment loses its encryption config? A policy catches it.
Together, they close a loop that's easy to leave open: you planned the right things (Playbook), you can measure whether the right things got done (Scorecard), and you can enforce the standards that keep things right over time (Policies).
Setting you up for success
None of this is magic. A Scorecard check for "does a Strategic Domain Model exist" can pass if someone creates a diagram with two boxes and a line. The tooling can verify structure; it can't verify thinking. The checks are a floor, not a ceiling, and the real architecture quality still depends on the people doing the work.
What AppFaktors does is remove the ambiguity around whether the work happened at all. It creates a shared, auditable record that's hard to fake and easy to review. For a consulting organization where the same patterns need to hold across dozens of projects and multiple teams simultaneously, that's exactly what you need. AppFaktors set projects up for success from design to done.
