|
||
|
Why Architecture Matters Five Fundamentals for Success Why IT Initiatives Fail Where to Begin About Us Contact Us |
Covalent Solutions Inc.®Bonding Business to Architecture & TechnologyWhy
Architecture Matters
Business owners/stakeholders consistently wonder why technology initiatives can't be better quantified. Technology professionals consistently wonder why their business counterparts are so reluctant to fund their initiatives. The problem is these two constituencies often speak very different languages. Business professionals speak/deal in very quantifiable terms, while technical professionals speak/deal in what appears to be a very abstract world. Both groups are conditioned by their responsibilities and environment to conduct themselves as they do. The result is--all too often--a very costly deployment of a technical initiative--funded by a business need--that leaves both constituencies feeling underwhelmed. The business people are dissatisfied with the time and effort involved in implementing the change, and the technical people are dissatisfied with the level of effort and justification required by their Line of Business counterparts--to secure necessary funding. Such initiatives require that people take into account the following (I would also suggest in the following order):
Many Organizational/Operational problems could be mitigated had their enterprise invested in the development and adherence to an Enterprise-wide Architecture. Unfortunately few corporations actually develop and/or adhere to Enterprise Architectural standards & principles. Instead, they consult with their vendor partners and/or 'Implementation' consulting firms--and those 'partners' draw only upon reference implementation models used by the vendor or consultant. While these reference implementations have value--they clearly do not address the enterprise, and rarely if ever do they complement the enterprise. They are designed to speed the implementation of a 'point solution'. We have observed that many organizations have 'standards' defined and adopted. But most adopted 'standards' amount to little more than 'supported configurations'. Again, this clearly helps constrain support costs--but it is not an architecture--nor is it a business enabler. In fact, often times those standards get in the way of business agility! Our name implies that we bring together the various constituencies of your organization and we do just that through a shared vision and common language. That vision is aimed at making your business more agile--not purely through technology--but through the application of appropriate standards, patterns, methods, models and architectural frameworks. In chemistry you will find some of the strongest atomic structures to be bonded based on the valence of atoms. Likewise we believe in business it is possible to form stronger bonds between Business and Technical stakeholders when you look for and achieve valence. Why select us to assist? Many Large firms have architects on staff or they have business partners who provide 'architectural services'. So, it would appear they have Enterprise Architecture covered, right? Not necessarily! If you are content with how technology in your company responds to your business needs, perhaps all is well and your enterprise is well understood and defined. But if you regularly find that your legacy infrastructure is inhibiting your ability to respond to new business needs/challenges perhaps it is your architecture--not your infrastructure--that is impeding your progress. We believe the definition of an Enterprise-wide Architecture has a lifecycle. And we further believe that lifecycle begins with the identification and declaration of business rooted principles. While the ultimate technology targeted to satisfy an architectural/business principle at any point in time may be abstract--the principle will be very concrete! You may ask--Are these exercises difficult? Yes they are--but they are clearly not a black art nor are they rocket-science. They can be accomplished simply by taking time to ask the correct questions up-front, then by mapping the answers to those questions to an architectural framework. The outcome of the engagement will not yield a directive to implement any given technology! Instead it will define what technology must be capable of doing to support the business. And the architectural principles will define these expectations with clarity and order/priority.
We have experience working with clients large and small to help facilitate the necessary interviews and conversations to define architectural principles. From there architectural frameworks, models, patterns and best practices may be applied to form an Enterprise-wide architecture. |
|