In our rapidly changing, yet knowledge-based business world, the discipline of business architecture is challenged in several ways:
• For years, organizations associated their transformation with IT development; their leadership learned to perceive success through the lens of their IT systems
• Heavy, lengthy, and expensive business architecture exercises created complex, though difficult to modify repositories of business knowledge, which were hardly utilized for pro-active business design, or IT development planning
• Striving to become more efficient, organizations turned to agile approaches, though frequently perceiving agility as strictly an IT virtue
• In pursuing agility, they strived to get rid of any influence of bureaucracy, sometimes counting the classic detailed business architecture and governance as bureaucracy too
• But deprived of consistent business knowledgebase, especially in highly complex interrelated businesses (e.g. government), “agile” IT endeavors could only address disconnected, visible on the surface solution points with high risk of omitting similarities in business functions (aka patterns) belonging to different, overlapping, or even redundant business areas... which misses the whole desired efficiency/agility point.
To address the above issues, the modern business architecture has no luxury to stay an academically snobbish “IT-agnostic” ivory tower discipline. In fact, it must become a “hub” for simultaneous targeting:
• True agility of Business (in absolute agreement with the “Business Agility Manifesto ®”)
• Its own agility (designing its knowledge base in a highly changeable, flexible way)
• And yes, agile IT delivery too.
The key to such business architecture is focusing on re-defining the business complexity in terms of highly reusable, independently re-designable, as-simple-as-possible, pattern-based modules (“construction blocks”), which
• Have clear boundaries, clear interactions with other business modules, and clear internal requirements
• May be utilized in multiple business processes of multiple lines of business
• May be out-sourced, in-sourced, or consolidated as internal/external business services
• May be rapidly modified by applying different sets of business rules, and
• Can be independently developed with agile IT methods (by designing the above modules to enable appropriate componentization for, say, SCRUM backlogs prioritizing/planning)
This case study looks at our experience implementing these approaches in several large public sector business transformation projects. We used the modified Government Services Reference Model (GSRM), case management, document management, notifications management and other patterns to construct the reusable business architecture modules.