11 days ago

New Enterprise “Cloud” Integration Approach in Banking

While all four maturing digital trends – Mobile, Cloud, Delivery Optimization, Process Optimization — are interconnected, Cloud appears to be the one to make the technology c-suite (CISO, CTO and CDO) most nervous. But the potential upside of Cloud adoption brings tremendous synergy in operating costs and also helps propel innovation.

24 days ago

The Open Group Ottawa 2017 – Event Highlights

The Open Group hosted over 300 attendees from 17 countries July 17 – 20 for the ‘Making Standards Work® e-Government’ event at the Shaw Centre in Canada’s beautiful capital city, Ottawa. It was a wonderful time to be in the country as Canada is celebrating its 150th anniversary!

26 days ago

Global TOGAF® 9 Certification Exceeds 70,000 in 134 Countries

Another milestone in the TOGAF® 9 certification program!  The number of individual certifications in the TOGAF® 9 certification program as of July 24 is 70,131. This represents over 12,000 new certifications in the past twelve-month period. TOGAF continues to be adopted globally with certified individuals from 134 different countries.

1 month, 14 days ago

The New Enterprise “Business” Integration Approach in Banking

We all know that Banks have been one of the early adopters of Service-Oriented Architecture (SOA) and Integration technology such as Enterprise Service Bus (ESB). Why was it imperative for banks to embrace SOA? The diverse enterprise eco-system centered on the core banking platform can easily become very complex with hundreds of interconnected systems built using diverse technology stacks and scattered around different geographical locations. It was either death by a thousand cuts or to adopt SOA, and wisely so, most banks chose the latter!

1 month, 14 days ago

On business-architecture and enterprise-architecture – why this matters

Okay, so I’ve ranted somewhat that placing a supposedly-‘new’ business-architecture ‘above’ enterprise-architecture is a bad idea, and added some further detail on how and why I think it’s a bad idea. But why does this matter? To anyone, really? Well, first,

1 month, 15 days ago

On business-architecture and enterprise-architecture – more detail

The key point from the previous post – ‘On business-architecture and enterprise-architecture‘ – was that we must stop misusing the term ‘enterprise-architecture’ for something that it isn’t. And we can even fix TOGAF so that it doesn’t make that mistake any

1 month, 21 days ago

Enduring Misconceptions about Architecture – Part 2

Tackling some key misconceptions about Enterprise Architecture can ease fear, uncertainty, and doubt about its effectiveness. The following list adds to misconceptions presented in Part 1 of this blog.

1 month, 27 days ago

The Present and Future of the ArchiMate® Language – Part 2

Welcome to the second in a series of blog posts on The Present and Future of the ArchiMate® Language. With the release of the ArchiMate 3.0 Specification last year, we now have a complete enterprise description language that has been adopted by architects worldwide in a wide range of organizations. It is now time for The Open Group ArchiMate Forum to reach out to users and better understand how the language is being used and how it should evolve. Therefore, the following post, like all others in this series, reflects the views of its authors, and will benefit from comments and discussion. You may refine, expand upon, or even disagree with elements of the post. Regardless, you will be shaping the future of the ArchiMate language.

So please, enjoy and engage!

2 months, 3 days ago

Challenges of Project Management on an EA-Driven Solution : A Blog Series

by Allan Borra, MSCS

Sitting as Project Manager AND Enterprise Architect

In a series of blogs, I’m sharing my experiences, challenges and eureka moments related to my dual role as a project manager and an architect to a solution development project driven by Enterprise Architecture.  I’ve managed  software solutions development projects before and have varying levels of applying project management disciplines and I’m usually using the software development lifecycle (SDLC) method. So it was a fun and learning experience for me to alter my usual “success” recipe by using Enterprise Architecture (EA) discipline in the mix. This methodology is similar to what is called Solution Architecture as defined by Gartner1.
It is observable that locally there are varying degree of awareness, compliance and maturity of Enterprise  Architecture work in organizations. I happen to be working for a pioneering and leading  EA consulting company who engaged a solutions development project for a government agency. The government agency has no enterprise architecture or capability  in place and the agency management has no (with some misconceptions even) to little  knowledge about Enterprise Architecture.

IT groups in government agencies, especially the one we are currently engaged in, are very comfortable with  traditional SDLC methodology. It fits nicely with the current government procurement law2. Nevertheless, we had a unique opportunity here to really push for an Enterprise Architecture-driven software development to complement the SDLC methodology (or any software development methodology for that matter), due to the fact that the terms of reference (TOR) explicitly calls out Business/Data/Application/Technology (BDAT) architecture requirements and standard notations such as Archimate.
Challenge 1: Changing Mindsets
Herein lies the first challenge: managing client expectations on project activities and deliverables. I’ve heard of an anecdote that goes “Change Management is easiest without people”. It was a really a concern  for me back then that the client wanted the solution as  soon as possible and that, even as the TOR calls out deliverables on BDAT architectures, these are not “primary” requirements for them. The client is accustomed to the SDLC or traditional methodologies that allow for only a certain level of business and functional requirements elicitation that is just enough for the software design and  implementation.  This meant that a semblance of the software solution could be out in a month or even as soon as  codes  are translated  from the functional requirements.

Figure 1. TOGAF Architecture Development Cycle
Enterprise Architecture, using The Open Group Architecture Framework Architecture Development Methodology (TOGAF ADM)3, entails going through different phases as shown in Figure 1. Critical to the requirements of the Terms of Reference for the project are Phases B, C and D. The method allowed us to view all their process documentations, if available, or elicit and model processes that are undocumented. These process models and artefacts take part in the Business Architecture. We then looked into their data both from a high or conceptual level and from a low or physical level. It took great lengths of mapping these conceptual data models to the business processes, moreso getting the complete business processes, interactions and information flows  documented themselves. Then we looked into their existing applications, modelled and related it to the processes to which these applications serve. We looked at their current infrastructure as well and modelled a target architecture by which the infrastructure can fulfill the requirements of the applications that services the processes that fulfills the intended performance of the solution that complies with the TOR. Needless to say, we considered legacy, third-party data and applications, out of scope processes in the mix of the overall  architecture. Ultimately, all of these need time without outputting a single line of code yet. Three months spent on EA work without a line of code yet for only a year-long project. For sure the client  was very impatient.
It was a painstaking “selling an idea, selling yourself” stint for me as I ventured in winning over the client and have them be on our side for this methodology: EA-driven solution development. What partly worked was communicating the value proposition of doing the EA work. For sure,  there’s tons of references out there that list these: 1. Alignment of technology to business strategies; 2. Aids in achieving business strategies; 3. Managing complexity of the enterprise; 4. Faster design and development of solutions; etc.. At the start of every meeting, I give a few minutes to orient key client stakeholders on the EA framework and the value this provide. The orientations ran for more than a month until we had some considerable artefacts and architectures to show for.  This worked in a way that when there are differences of expectations, it’s always a heavy, difficult conversation with clients, while, if there’s a level of agreement on expectations, conversations are smooth and affable. And we are having these kinds of conversations, already. But I did mention that communication only partly worked, because at the end of the day, there’s still no solution or line of code to show. I just can’t take all of that away from them, for now.

And then, eureka! The architecture surfaced the complexity!  When one can visually breakdown a complex network of interacting components and dimensions of the organization, or in this case, the solution and its  interactions with the organization, managing all of that becomes simple.  In my next blog, I’ll discuss how EA + tool shows the complexity and how it aids the communication: bringing the client to our side. I’ll share as well,  how visualizing the complexity helped me as PM  with decision-making based on these architecture artefacts.



1Gartner IT Glossary: Solution Architecture. Accessed June 2017. Retrieved from

2Government Procurement Policy Board. Republic Act 9184: Government Procurement Reform Act. 2002. Retrieved from http://www.gppb.gov.ph/laws/laws/RA_9184.pdf

3TOGAF® 9.1 Part II: Architecture Development Method (ADM). Introduction to the ADM. 2011. Retrieved from http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html



Talk to Us.

© Sinag Solutions

Unit 903, Antel Global Corporate Center, Julia Vargas Ave, 

Ortigas Center, Pasig City, Philippines, 1605

Office: (632) 956 5175

2 months, 12 days ago

The Present and Future of the ArchiMate® Language – Part 1

Welcome to the first in a series of blog posts on The Present and Future of the ArchiMate® Language. With the release of the ArchiMate 3.0 Specification last year, we now have a complete enterprise description language that has been adopted by architects worldwide in a wide range of organizations. It is now time for the ArchiMate Forum to reach out to users and better understand how the language is being used and how it should evolve. Therefore, the following post, like all others in this series, reflects the views of its authors, and will benefit from comments and discussion. You may refine, expand upon, or even disagree with elements of the post. Regardless, you will be shaping the future of the ArchiMate language.

So please, enjoy and engage!

2 months, 26 days ago

Why More Industries are Turning to Open Standards

Many enterprises and their industries are aggressively addressing the need to implement digital and global business models. Increasingly those industries and groups of industries are looking to The Open Group for guidance as to how they can effectively both develop and use standards to accelerate the journey they see ahead, in the private and public sectors.