Sunday, January 31, 2016

Don't Sacrifice Your Business Architecture

Business architecture is core for an organisation’s Enterprise Architecture. Both the leading Enterprise Architecture frameworks, TOGAF and Zachman advocate Business Architecture to become a fundamental corner stone of Enterprise Architecture. Business architecture is about not just about business process modelling and business capability definition on a project to project basis. I think it is also about defining the Target Operating Model of the organisation. I have personally experienced the power of applying pragmatic business architecture to model current (as-is) and target (to-be) business operating models.
However Business Architecture is not easy to deliver on. An organisation needs skilled and experienced practitioner architects to engage stakeholders, establish relationships to understand and model the business capabilities, business processes workflows etc. Business architects should ideally also need reasonable domain knowledge of the respective business to make a meaningful contribution in the design of such model. Otherwise that individual runs the risk of becoming simply (an expensive) documentation resource.
These days often the funding for Enterprise Architecture is limited and high priority projects and programs are often competing for best resources and funding. In these situations often the Business Architecture resources are sacrificed to make way for technical architects (e.g. infra, integration). In such scenarios an organisation runs the risk of doing Enterprise Architecture without Business Architecture. This probably results in this organisation doing IT Architecture rather than Enterprise Architecture. See below graphic. 
It will probably still deliver value by bringing structure, discipline, visibility and planning to the critical IT project delivery. However these efforts risk falling short of becoming something much more meaningful and sustainable investment for business and not just IT.

I strongly feel that organisations should not sacrifice Business Architect. When resource and funding is limited, instead such organisations should find clever alternative ways to resource them. Some of the options which have worked for me in the past are;
  • Get your most important projects to fund it and then expand that to Enterprise level
  • Use your experienced application or data architect to play the role of Business Architect in the interim
  • Leverage your strategic partners / suppliers to perform this role
  • Leverage your customers / internal business stakeholders to play this role directly and indirectly. I came across an excellent real life use case of this recently. More on this in next post.

Monday, June 1, 2015

Shifting IT Operating Models


Just came across an interesting post by Colin Bannon, CTO BT this morning. The infographic which he has shared compares and contrasts the Old or a more traditional operating model of IT with a new, evolving operating model of IT. While I have first-hand experienced this dramatic change through my recent roles in Digital Transformation in Retail and Financial Services, the infographic drives home the key transformation points really well. Gone are the days of traditional and conventional Pyramid of IT organisation hierarchy towers where the change is driven from the top IT leaders such as CIO, CTO and their teams. Instead now what we are witnessing is more decentralized, dynamic, agile change driven by smaller, more focused teams coming not just from IT but Operations, Finance, Marketing, Sales and even Business user communities. 
I have experienced that such change is often driven by "here and now" market opportunities where the business can make immediate inroads to new opportunities or indeed react faster to emerging trends / threats. This model challenges the traditional waterfall model of doing things right from business case down to engineering and service release. I think a number of maturing trends have helped drive this; Agile, DevOps, Cloud Ecosystems, BYOD, Open Source, API platforms, Social Media and Mobility, all have helped fuel this trend. This is certainly not for faint-hearted and the pace of change is often breathtaking. But I have personally enjoyed my journey from a more traditional CTO to much more dynamic, agile and proactive CTO in the past three years. What this has meant for me is to find opportunities to make genuine difference to my business and enable them to grow past traditional IT operating model obstacles. Traditional IT Op Model is dead. Long live new IT! 

Monday, November 17, 2014

Are you Teaching a Starving Man to Fish?

Are we as Enterprise Architects guilty of teaching a starving man to fish? I came across a blog post with similar title by Bruce Kasanoff this morning. What a great little article from Bruce and what a punch of a message! It resonated so well with what I have observed in the field of Enterprise Architecture over the past decade or so. 

Whether we like it or not, sometimes Enterprise Architects are seen as a bunch of guys who are running "ivory tower" practices. Some brilliant, intellectual stuff takes place in such practices but often it seems to fail to solve real-world, practical problems. We have some good models, framework, methods but somehow the customer of our trade do not seem to find it useful. Why would this be happening? 

Here is one scenario, borrowing Bruce's metaphor from above. Our "starving man" customer approaches the talented and experienced Enterprise Architecture team expecting a "fish today". This may be in the form of a solution to a specific burning project problem, e.g. integration requirement for a new digital channel and legacy back-office. They probably expect us to deliver a crunchy API specification in quick time so that they can hand it over to third party supplier. But instead they get a dose of methods about taxonomies and generic models.

The intent here is probably noble so as to empower project teams to build interfaces based on corporate standards which are perfectly aligned with the "right EA way". But probably what the customer expected was an Enterprise Architect to drop his methodology chalks, roll up his sleeves and do some real work to deliver "fish today" integration specification. And once the hunger was tackled, this starving man would be ready to learn "fishing the EA way" based on delivery credibility for future integration work. 

The point I am getting at here is Enterprise Architects need to maintain a healthy balance between framework purity and practical implementations in real-life. Solving some project / solution problems here and now may be the best way to educate about the value of Enterprise Architecture. And then we will have a ready audience who will be interested in learning more about our great taxonomies and models to solve further real-world problems in future. If we don't, the customer will sooner than later go somewhere else where he gets a fish when he is hungry. Have you heard about "Shadow Architecture Team" by the way? 

Happy Fishing!

Blog Archive