Saturday, August 05, 2006
Should Chief Security Architects understand Business Architecture?
We live in a world of Sarbanes Oxley, HIPAA and other legal and regulatory acts. The funny thing is that most security architects haven't figured out where the desires of the business converge with their own...
I have created a bulleted list of desires that are common by both parties:
The funny thing is that most folks that discuss business architecture and how it has the potential for enabling agility within the enterprise haven't connected it to requirements that should be placed on chief security architects. If business architecture is to enable agility, it does beg the need for IT to enable rapid business moves without resulting control problems. Likewise, it the climate of constant organization chart changes, the chief security architect should be thinking of ways to provide enough flexibility to assign administrative priveleges, set system change management authority, and provide clear separation of roles, all within a rapid timeframe.
Business sometimes desires the agility to buy and sell companies without pain. It has been well articulated that IT system migration is painful but many folks are letting the security folks off the hook when maybe the bigger problem is not just integration of core systems but also integration of internal controls.
Maybe a business architect should understand not only IT controls but assist in making them flexible? What would happen if a business architect became the champion of not just agile methodologies such as SCRUM for project management and extreme programming for software development where they improved IT delivery of projects but took it one step further? If a business architect embraced the COSO framework and relevant COBIT guidelines and outlined to others high-priority control objectives, they may be able to solve multiple issues at the same time.
I have several initiatives that I am savagely pursuing and would love for a business architect to step up and provide amplification. I wonder if the business architects out there have ever noodled why us security guys are so passionate about user identity management? Do you think it may allow for us to change role configuration in the same time cycle as business agility dictates? If so, amplify!
Compliance itself can become agile but requires a level of unity where IT and business can understand and implement the IT aspects of internal controls. This begs not only coordination but also comprehension and communication. Another potential convergence point is via the use of service-oriented architectures. Compliance can become a service. The folks over at Redmonk not only get this but have published a wonderful paper entitled: Compliance Oriented Architectures.
You could be agile and compliant without an SOA, but an SOA has the potential to make the job a lot easier. SOA has the potential to enable agile compliance because it solves some of the cycle time challenges of matching the software change management process to the business agility requirements. By leveraging a common way of creating services using an enterprise service bus such as ServiceMix compliance can become built-in.
Maybe, business architects are still attempting to figure out what business architecture is. Maybe they have gotten it twisted and haven't yet figured out that they should stop listening to analysts as their conversation is usually about product and not architecture. Maybe, they should defer some of their own thinking to all wise chief security architects? Miminumly, we need to change the conversation...
| | View blog reactionsI have created a bulleted list of desires that are common by both parties:
- Accurate, timely financial reports
- Pass SOX audit and fiscal audit without incurring excessive annaul fees from consultants
- 360-degree view of customer and business
The funny thing is that most folks that discuss business architecture and how it has the potential for enabling agility within the enterprise haven't connected it to requirements that should be placed on chief security architects. If business architecture is to enable agility, it does beg the need for IT to enable rapid business moves without resulting control problems. Likewise, it the climate of constant organization chart changes, the chief security architect should be thinking of ways to provide enough flexibility to assign administrative priveleges, set system change management authority, and provide clear separation of roles, all within a rapid timeframe.
Business sometimes desires the agility to buy and sell companies without pain. It has been well articulated that IT system migration is painful but many folks are letting the security folks off the hook when maybe the bigger problem is not just integration of core systems but also integration of internal controls.
Maybe a business architect should understand not only IT controls but assist in making them flexible? What would happen if a business architect became the champion of not just agile methodologies such as SCRUM for project management and extreme programming for software development where they improved IT delivery of projects but took it one step further? If a business architect embraced the COSO framework and relevant COBIT guidelines and outlined to others high-priority control objectives, they may be able to solve multiple issues at the same time.
I have several initiatives that I am savagely pursuing and would love for a business architect to step up and provide amplification. I wonder if the business architects out there have ever noodled why us security guys are so passionate about user identity management? Do you think it may allow for us to change role configuration in the same time cycle as business agility dictates? If so, amplify!
Compliance itself can become agile but requires a level of unity where IT and business can understand and implement the IT aspects of internal controls. This begs not only coordination but also comprehension and communication. Another potential convergence point is via the use of service-oriented architectures. Compliance can become a service. The folks over at Redmonk not only get this but have published a wonderful paper entitled: Compliance Oriented Architectures.
You could be agile and compliant without an SOA, but an SOA has the potential to make the job a lot easier. SOA has the potential to enable agile compliance because it solves some of the cycle time challenges of matching the software change management process to the business agility requirements. By leveraging a common way of creating services using an enterprise service bus such as ServiceMix compliance can become built-in.
Maybe, business architects are still attempting to figure out what business architecture is. Maybe they have gotten it twisted and haven't yet figured out that they should stop listening to analysts as their conversation is usually about product and not architecture. Maybe, they should defer some of their own thinking to all wise chief security architects? Miminumly, we need to change the conversation...
