by Vish Viswanathan | Jun 10, 2020 | BIAN
As a BIAN member with a global footprint, CC&C is proud to be a premier launch partner for BIAN Foundation training. We are helping financial institutions, services companies and individual practitioners to get ready for BIAN.
We offer training worldwide over Zoom, delivered by experts in BIAN and the banking industry.
The BIAN Standard
BIAN is a unique and purpose built framework designed by Banks of Today for Banks of Tomorrow. We at CC&C are excited to be a part of this ground-breaking initiative, which will have a profound impact and can vastly accelerate a bank’s digital transformation journey.
Adopting BIAN results in a cohesive, open-standard based, future-proofed and scalable architecture. This is a crying need in the banking sector, where interoperability and a robust open API standard work to support Open Banking, integration with partners and business flexibility.
BIAN’s positive business impact will be felt by all of us, whether we are a bank’s customers, shareholders or service providers.
With the release of BIAN certification and BIAN foundation training, the groundwork has been laid for a new professional community/
The BIAN Organization
Established in 2008, the Banking Industry Architecture Network (BIAN) is an independent, member owned, not-for-profit association, designed to build and promote a common architectural framework for banking interoperability issues. BIAN’s goal is to define SOA and semantic definitions for IT services in the banking industry. The community, of over 60 members, focuses on creating a standard semantic banking services landscape, while ensuring consistent service definitions, levels of detail and boundaries. This will help banks to achieve a reduction of integration costs and use the advantages of a service-oriented architecture.
Financial institutions, software vendors, and system integrators, along with technology partners, are invited to join the association and play a collaborative role with other industry leaders in defining, building and implementing next-generation banking platforms.
by Vish Viswanathan | May 22, 2017 | Architecture
Finding Your Next Steps
After getting TOGAF certified, what’s next on your architecture career journey? When speaking to a team of newly certified TOGAF® architects at a customer organization, most of the questions were centered around this, such as::
- How do I get started with my first EA project using TOGAF?
- How do I estimate EA projects?
- How do I create an EA Repository?
- How essential are modeling skills?
As the questions kept coming in, it was clear that we weren’t yet differentiating between the three big buckets of work outlined in TOGAF, that is:
- Creating an architecture practice
- Running an architecture project
- Governing the enterprise’s architecture
The certification process provides one with a good conceptual knowledge of TOGAF and EA, but doesn’t really clarify these three big buckets or talk about how to put your new knowledge about each of them into practice.
Here are a few tips on the most important of the three big buckets to a new architect:
Three Things to Remember
First, learn when to start and when to end the EA project. You are covering phases A through F of the TOGAF ADM. You are not overlapping with the actual design and development of the software!
Second, the time you spend and the quality of work you do in the ‘A’ phase of the ADM will decide the overall success of the project. Here are some things to consider:
- A discovery workshop can bring clarity in terms of the issues, goals, gaps and scope. Bring your business and IT teams together on the same page and watch them argue and differ on challenges, gaps and issues.
- Developing an EA value proposition for the specific project is one of first things to do to communicate value to your stakeholders. It will also help keep you focused on always delivering business outcomes.
- Develop and demo a few sample EA artifacts using an EA tool. Try these out with friendly stakeholders to see how they resonate. Be sure to reuse templates from others in the organization that have worked before.
Third, remember, you are running an architecture PROJECT. Treat it as a project, just like any good PM would do.
- Create EA project estimates based on how many business units are participating, roughly how many business processes you are addressing and their complexity. To get the hang of it, dig into process documentation, application code and workflows, and database tables. Interview stakeholders. Be ready for site visits such as call centers, data centers, corporate offices, warehouses, and so on.
- Develop an EA roadmap that clearly highlights milestones and deliverables in a way that anyone can understand.
- Business process modelling is best approached from the organization chart. For each business unit, model high level processes and then drill down to the next levels. Develop your own hierarchy of business services -> business processes -> business sub-processes -> application functions, etc. Then you can rationalize back up into business capabilities. Trying to work from business capability first rather than org structure is actually much harder for your customers and stakeholders to understand up front.
- Demand the right kind of people: Since EA is a horizontal function, it draws resources (architects) from the line of business or business units for the duration of the EA project.
- Use the right tools: Many EA tools have good TOGAF plug-ins that can guide you through the ADM phases. Use one if you can.
- Be flexible: There is no need to strictly adhere to a TOGAF way of doing things. As long as you follow the general philosophy and the ADM flow, that should be enough.
Earn Respect with Consistency
Remember, every customer use case is unique, but the TOGAF approach is more or less the same. As long as you can show incremental value to your stakeholders by creating artifacts to convey direction or highlight process gaps or drive organizational reuse, you are definitely in the game.
