I think my company EA leaders have read the same material that this week's lesson material is based on as it reflects almost exactly exactly the internal structure of our EA division. However we have some variation. Our organization includes the Business, Technology, Data and Security Architecture domains set up as individual groups. However, with Application Architecture, we split this into 5 separate Portfolios, which mirror the major Business Divisions of our company. This is mainly because the first four areas are primarily funded from the central IT budget, where as applications are funded by the corresponding divisions and typically only connect to other applications within the business. This has caused some friction as control of individual application's architecture and budget are closely guarded and acceptance of any central influence over either has not been fully successful in my opinion. This limited success, I believe, was due to the fact that we used a strict governance model. It was seen as nit-picky and a hindrance. We switched to a model where we provide recommendations, with visibility to higher management. It is more of a guilt/peer pressure approach.
I did have one issue with the lesson. It describes Security Architecture as “the artifacts that describe how the security controls ..." I would strongly argue that Security Architecture in more than just artifacts. A comprehensive Security Architecture includes implementation of implemented security mechanisms, such as Firewalls, intrusion detection, secure development practices, etc. I wonder where Wikipedia would place these components in its EA framework?
No comments:
Post a Comment