TOGAF Foundation

A long awaited first architect level certification of mine, though foundational level, serves as a catalyst to boost value for my employer and clients. It is not a tough paper to pass, comparing to its Part 2 brother. I listed the materials that I used for examination preparation below:

• TOGAF Version 9.0 documentation (Optional but recommended, especially if you are like me going for Part 2 soon)


• TOGAF 9.0 Foundation Study Guide (Sufficient to pass part 1 but hardly flying color)


• Misc. TOGAF 9.0 Summary documents (For understanding only)


• Few years of architecting experiences (Optional but useful for really understand TOGAF values)

My score was 93% which is aligned with my usual passing standard. I think preparation works for Part 2 would be more interesting because it requires drilling deep into in-and-out of TOGAF 9 specification. Sounds fun!

Making sure XBRL kissing and not kicking you!

During the course of my professional career, may it be in business or information technology, I have seen and heard innumerable hypes and promises of disrupting standards, paradigms, solutions and technology advancements. Usually, mega-vendors with plentiful of marketing capital will succeed in planting seeds to gain buy-in and yet losing momentum when the trend reaching a critical mass of demystification and finally the bubble busted and they move on to another vicious cycle of hype-high-haunt. History is likely to repeat itself and what businesses can do to protect their valuable capitals is to put in the right perspective and context in understanding the impact and risk in adopting certain approach to meet competitive advantage demand, market pressures, regulatory (BNM NSRS ISS) requirements and et cetera.

Life’s tough but that’s life.

I would like to focus the spotlight in this post to be pertinent about Extensible Business Reporting Language, or commonly known as XBRL. I think I will most likely skip all the boilerplate explanation and description of what XBRL is and some common sense facts about it that you and I can reason without any significant efforts. I am more interested in shedding light about best practices, prevention measures, implementation management and techniques for making sure proper alignments between domains of business, data, application and technology.

To make this even more interesting, I am also doing some thoughts about topics such as BPO model to XBRL, the problem of agility mismatch and other matters.

Just close your eyes and imagine for a while the ideal state of anything that is perfectly blended into our life. How would we perceive them? The ideal case is that we don’t even need to know about their existence since they are so well blended into our daily routines or activities; we just take them for granted. For instance, we don’t need to know how an automobile’s engine works in order to drive a car. We can study about them if we have the luxury of time and resources, and at our will.

Same scenario is here for XBRL. The current proliferation of standalone XBRL conversion tool demands understanding of intricacies of XBRL to fully harness the real benefits of XBRL. The fact that these tools are standalone, single purpose built applications meant the chasms to enable seamless information flow is predicted to be more challenging than a proper solution with a long term interoperability vision. Information management in XBRL can be chaotic without built-in functionalities within the tools to perform auditing, archiving, versioning, automated and human workflow process for validation. The business might ends up with a mess of thousands of scattered XBRL taxonomies and instances with no tractable ways to consolidate them.

Have something better and let standalone XBRL conversion tool be the last resort.

My point is clear and obvious, a standalone tool could be suffice for relatively small company with human manageable size and complexity of XBRL artefacts, however it is not suitable for large corporations such as financial institutions, conglomerates and federal agencies. Operational expenditure of using standalone XBRL tool is forecasted to be exceedingly high compared to an enterprise grade XBRL solution. Next is the impact to the corporation’s evolve-ability and maturity level in enterprise data management, especially when XBRL artefacts are not meant to be the end, but only a means to the standardized information sharing platform. This is one critical area where technological advancement is needed to accelerate the adoption of XBRL because it is virtually hard to find commercial data integration tools that can natively process XBRL format. At the moment, these tools can only parse and understand XML format. XML and XBRL are not the same, we all should know by now right? One of the database vendors is coming up with a database vault that can process XBRL natively; however we are yet to see their releases and feature sets.

Aim for centralized management and governance model.

The sole action of buying a standalone XBRL conversion tool without a much higher level enterprise planning process is like buying and driving a car in a poor city planning area where you have no idea whether there is proper road in front of you. Still, the car will move and you might eventually reach your destination, well, predictably in a stochastic and risky way. The bottom line to use a standalone XBRL conversion toll is that even if you have decided to adopt the tool, please request your vendor or internal governance team to come up with a comprehensive strategy and future transitioning plan for it.

Prioritize and focus on the business values.

Avoid been inundated with XBRL related jargons and terminology because a well-planned business application using XBRL shall abstract most of these technicalities from business users, even power users. I know the in-and-out of XBRL because I spent quite a fair amount of time in understanding their specifications and business orientation. At the basic, XBRL got at least 3 specifications to be understood plus all the related XML related specifications; I bet my clients won’t have the luxury of resources to skimp them thoroughly. On top of everything, there are global standards such as IFRS, US-GAAP, GRI and many more to be adhered to govern a business. So, when possible, procure a complete business solution that designed at the proper level of technical abstractions.

Know your opponent’s agility.

In a regulatory landscape where regulator (e.g. BNM NSRS ISS) requires monitoring and compliance submission information from regulated entities, these entities should know the capability and agility of their regulator to pick the right XBRL solution. Let me explain the idea in more details. You see, regulator is implementing XBRL solution for say regular financial statement submissions from regulated entities. There are valid rationales and implications of why they do so. One of them is to progressively increase their capability of requesting and consuming more detailed, more frequent and more accurate information and catch up with regional and global peer pressures in adopting evolving industry standards.

Once the regulator possesses this agility, regulated entities will face what I coined the problem of agility mismatch, if they didn’t level up in this playing field. To meet the initial regulatory and compliance requirements mandated by regulator using the new XBRL platform is relatively simple for basically whichever approach that regulated entities adopted, may it be standalone XBRL tool, and enterprise integrated solution or even pure human solution. The real issue is the size, complexity and interval of future changes that regulated entities faced. Regulated entities most likely will caught in a downward spiral of catching up with the reporting changes. Money can be spent better elsewhere don’t you think so?

XBRL is at the centre of information nexus.

It is very ideal indeed to position XBRL like this and I think is risky because supporting tools, standards and technologies are not there yet to reinforce the implementation. Nonetheless, XBRL can really be used to supplement the organization’s effort in consolidating master data, reference data, metadata and their governance initiatives. Don’t lock the value of XBRL in a silo. XBRL is significantly much better than any ad-hoc and in-house standardization efforts such as creating a XML based data sharing format, standardized document structures and tons of other such things you and I have seen. XBRL is developed to solve many of these repeating and known problems. Why not leverages XBRL but reinvents this ugly wheel?

Lastly of this post, I don’t favour the idea of engaging a BPO vendor to take care of the organization needs to be transited to the paradigm where XBRL is used for regulatory and compliance requirements. I think XBRL is here to stay and getting more ubiquitous, pervasive and critical for businesses to stay relevant, competitive and agile. XBRL can be a socio-technical object transforming the way we handle business information.

I will write more of my thoughts out in the future about this topic. Pen down.