Tag Archives: togaf

Togaf Phase Tags

Welcome to the NZRT Wiki Podcast. Today we’re looking at TOGAF Phase Tags.

If you’ve spent any time in the NZRT forum, you’ve probably noticed that discussions are organised by tags. For TOGAF work specifically, those tags map directly to the ADM phase cycle, and understanding how they fit together makes navigating forum content a lot easier.

Let’s start with the phase tags themselves. There are ten of them covering the full TOGAF ADM lifecycle. The Preliminary phase uses the slug preliminary-phase and has a tag ID of 5. Phase A, Architecture Vision, is phase-a with ID 6. Phase B, Business Architecture, is phase-b with ID 7. Phase C, Information Systems, is phase-c with ID 8. Phase D, Technology Architecture, is phase-d with ID 9. Phase E, Opportunities and Solutions, is phase-e with ID 10. Phase F, Migration Planning, is phase-f with ID 11. Phase G, Implementation Governance, is phase-g with ID 12. Phase H, Change Management, is phase-h with ID 13. And finally, Requirements Management uses the slug requirements-management with ID 14.

Beyond the phase-specific tags, there are eight general-purpose tags. General is ID 15, Tasks is 16, Announcements is 17, Dev is 18, API is 19, and then three business unit tags: ICS at 20, ITE at 21, and NCS at 22.

Now, here’s the practical detail you need to know depending on what you’re doing. When you’re creating a new discussion using the forum tool, you pass the slug string directly into the tag parameter. So you’d write something like phase-f, and the tool resolves that to the correct numeric ID internally. You don’t have to worry about the numbers at that point.

However, if you’re patching an existing discussion to add or change a tag, the numeric ID is required. And there’s an important constraint here: you can only apply one tag per patch request. If you try to include multiple tags in a single patch, you’ll get a 500 error. So keep those calls separate. Also worth noting, you must use Python for patch operations. PowerShell fails because of how it handles CSRF tokens.

On the topic of filtering discussions by phase, the wiki includes an example of the API call you’d use. In plain terms, it’s a GET request to the forum’s API, pointing at the discussions endpoint, with a filter parameter specifying the tag slug you want and a page limit of up to 50 results. You use the full slug, so phase-f rather than any shortened version. If you’re using curl on the command line, you need the -g flag to stop curl from misreading the square brackets in the URL as glob patterns.

Putting it all together in the TOGAF workflow: at each ADM phase, a script called create_togaf_phase_tickets.py is run with the phase letter as an argument. That creates eight agent tickets, one per agent. Each agent then posts their forum discussion under the relevant phase tag. Once all eight discussions are up, both xc and cla review them before the gate sign-off document is produced. The tags are what keep all of that content organised and filterable throughout the process.

So in short, slugs for creating, numeric IDs for patching, one tag per patch, and always Python for forum write operations.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Togaf Application Platform Service Categories

Welcome to the NZRT Wiki Podcast. Today we’re looking at Togaf Application Platform Service Categories.

If you’ve ever wondered what sits underneath an enterprise architecture — what kinds of services an application platform actually needs to provide — this episode breaks that down for you. TOGAF defines a comprehensive set of service categories, and together they describe every major capability a platform must support. Let’s walk through them one by one.

We start with Data Interchange Services. These cover how data moves and transforms between systems. Think document typing and conversion, graphics interchange, electronic data interchange, fax services, and raw graphics interface functions. It also includes text processing, document processing, publishing, video, audio, and multimedia processing functions, along with media synchronisation, information presentation and distribution, and hypertext functions. Essentially, anything to do with getting data from one form or place to another.

Next are Database Management System services. These include object-oriented database management, file management, query processing, screen and report generation, networking and concurrent access, and data warehousing. These are the services that let your platform store, retrieve, and present structured data.

Graphics and Imaging Services cover graphical object management, drawing services, and imaging functions. If your platform needs to render or manipulate visual content, this is the category that supports it.

Location and Directory Services are all about finding things. Directory services, special-purpose naming, service location, registration, filtering, and accounting services all live here. These help systems and users locate resources across a network.

Network Services are broad. They cover data communications, electronic mail, distributed data and file services, distributed naming and time services, remote process access, and remote print spooling. On top of that, you’ve got enhanced telephony, shared screen functions, video conferencing, broadcast functions, and mailing list functions. This category is the backbone of how distributed systems talk to each other.

Operating System Services keep things running at the foundation. Kernel operations, command interpreter and utility services, batch processing, and file and directory synchronisation services all sit here.

Software Engineering Services support how software is built. This includes programming language services, object code linking, computer-aided software engineering tools, graphical user interface building, scripting languages, language bindings, run-time environments, and application binary interface services. If you’re building or deploying software on the platform, these services are what you depend on.

User Interface Services are what users actually interact with. Graphical client and server services, display objects, dialogue support, printing, computer-based training and online help, and character-based services all fall into this category. This is where the platform meets the person.

Security Services are critical. You’ve got identification and authentication, system entry control, audit services, access control, non-repudiation, security management, trusted recovery, encryption, and trusted communication services. Together these ensure that only the right people and systems can do the right things, and that there’s a record when they do.

System and Network Management Services cover the operational side of keeping everything running. User management, configuration management, performance management, availability and fault management, accounting management, print management, network management, backup and restore, online disk management, licence management, capacity management, software installation, and trouble ticketing services. This is your operations team’s toolkit, built into the platform definition itself.

Finally, Object Request Broker Services handle distributed object communication. These include implementation repository services, installation and activation, interface repository services, and replication. Then there’s a rich set of common object services covering change management, collections, concurrency control, event management, externalisation, licensing, lifecycle management, naming, persistent object services, properties, query services, relationship services, start-up services, time services, trading services, and transaction services. This category is what lets distributed components find each other, communicate reliably, and maintain consistency across a system.

So when you look at all of these together — eleven major categories, hundreds of individual service types — you get a picture of just how comprehensive the TOGAF application platform model is. It’s not just about what your application does. It’s about every layer of capability the platform must provide to make that application possible.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.