Hi again
I found an interesting piece of article describing in a few short words some of the architecture problem space, found it interesting and entertaining. I think it's worth reading - it's aimed at architecture professionals and laymans alike :)
http://www.infoworld.com/article/2949922/enterprise-architecture/5-steps-to-becoming-an-enterprise-architecture-ninja.html
luni, 25 ianuarie 2016
marți, 23 iunie 2015
Writing code
I will discuss in the following about bug and software development in general.
I was reading an article about what a good programmer is. The article contained a few good points, clearly matched by my previous experience. While I may not necessarily agree with the rest of the points, I found the ones below of significance.
"This is also about how we define quality and what a bug is. If we look at a traditional and very "intuitive" definition of a bug, it is something that causes our software to produce an incorrect or unexpected result. However, if we think more about how the software is actually used and by whom, we'll see that there are many other types of bugs, including scalability, reliability, and even maintainability ones."
"If we put all those "-ilities" in a list and prioritize them by their severity and importance to the business, we'll see that functionality-related bugs are rather far from the top. I would actually put maintainability at the top."
I was reading an article about what a good programmer is. The article contained a few good points, clearly matched by my previous experience. While I may not necessarily agree with the rest of the points, I found the ones below of significance.
"This is also about how we define quality and what a bug is. If we look at a traditional and very "intuitive" definition of a bug, it is something that causes our software to produce an incorrect or unexpected result. However, if we think more about how the software is actually used and by whom, we'll see that there are many other types of bugs, including scalability, reliability, and even maintainability ones."
"If we put all those "-ilities" in a list and prioritize them by their severity and importance to the business, we'll see that functionality-related bugs are rather far from the top. I would actually put maintainability at the top."
"My point is that mistakes are not all equal. If I'm writing a PDF report generated by a piece of Java code and my report misses the footer, that's one type of bug, and its fix will cost the business X dollars. On the other hand, if my PDF generation code is so difficult to modify that in order to change its format from A4 to US Letter we have to rewrite it from scratch, that's a completely different type of bug. Needless to say, its fixing will be many times more expensive."
"There are exceptions, of course, where the business prioritizes functionality above everything else, but such situations happen very rarely (if the business is smart)." - however, the technical architect also has a role here to try to make things happen by this rule).
vineri, 12 iunie 2015
Organization and Architecture
Learning something new every day :)
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
-- Melvyn Conway, 1967
vineri, 8 mai 2015
Microsoft reference architecture for banking
I spent some time documenting myself about Microsoft offerings for banking industry and I came across MIRA-B.
What I found interesting about this paper is that it covers in a clear and concise manner the business architecture from the banking perspective - challenges and goals for the banking sector, as well as a current snapshot of the trending market forces.
One example of some other forces disrupting the market is Apple Pay.
Here's the link, enjoy :)
http://www.microsoft.com/enterprise/industry/financial-services/banking-and-capital-markets/reference-architecture/default.aspx#fbid=onVDsDrUuky
What I found interesting about this paper is that it covers in a clear and concise manner the business architecture from the banking perspective - challenges and goals for the banking sector, as well as a current snapshot of the trending market forces.
One example of some other forces disrupting the market is Apple Pay.
Here's the link, enjoy :)
http://www.microsoft.com/enterprise/industry/financial-services/banking-and-capital-markets/reference-architecture/default.aspx#fbid=onVDsDrUuky
miercuri, 25 martie 2015
EA
Enterprise Architecture
I did some study on TOGAF framework for my Open Group TOGAF 9.1 Certification Exam.
With this occasion, I took some time to think about it and came up with some opinions and ideas. Some of these could be found below.
I think there are some challenges on implementing it within enterprises:
1. The technique to trim it down to a specific enterprise as needed in order to be easy to use within the enterprise - this also pertains to the key people and processes - think of it as a custom tailoring of the TOGAF framework for the enterprise it you will. All this would require a significant amount of experience from the person driving this effort. One could say that the activity to understand the specific business organization (not only processes but people and relationships) and to tailor the framework accordingly is also an art.
2. Triggering these kinds of changes within enterprises will always be challenging. That is, change, support and trigger the transformations within the enterprises in order to establish the enterprise architecture capabilities.
3. My opinion remains that - and this is not something I read during my study - one must tailor and apply the TOGAF framework in an agile way. The enterprise architecture capability and its processes should be designed with agility in mind, even for large enterprises. Creating large amount of documentation, difficult to read and understand - much less to apply, as well as having complicated and time consuming architecture requirements management and governance processes is not going to help too much in this area. I think that these enterprise capabilities should ensure that the IT supporting the enterprises is aligned to the business vision and requirements - but they need to do so in an agile way.
So, is TOGAF useful? I think very much so. But in the end it's just a framework with a vision - the real challenge will rest on the shoulders of people that are going to apply it - as always, an idea (strategy) however great remains an idea if you do not have the right people to understand it and execute on it ;)
Have fun
I did some study on TOGAF framework for my Open Group TOGAF 9.1 Certification Exam.
With this occasion, I took some time to think about it and came up with some opinions and ideas. Some of these could be found below.
I think there are some challenges on implementing it within enterprises:
1. The technique to trim it down to a specific enterprise as needed in order to be easy to use within the enterprise - this also pertains to the key people and processes - think of it as a custom tailoring of the TOGAF framework for the enterprise it you will. All this would require a significant amount of experience from the person driving this effort. One could say that the activity to understand the specific business organization (not only processes but people and relationships) and to tailor the framework accordingly is also an art.
2. Triggering these kinds of changes within enterprises will always be challenging. That is, change, support and trigger the transformations within the enterprises in order to establish the enterprise architecture capabilities.
3. My opinion remains that - and this is not something I read during my study - one must tailor and apply the TOGAF framework in an agile way. The enterprise architecture capability and its processes should be designed with agility in mind, even for large enterprises. Creating large amount of documentation, difficult to read and understand - much less to apply, as well as having complicated and time consuming architecture requirements management and governance processes is not going to help too much in this area. I think that these enterprise capabilities should ensure that the IT supporting the enterprises is aligned to the business vision and requirements - but they need to do so in an agile way.
So, is TOGAF useful? I think very much so. But in the end it's just a framework with a vision - the real challenge will rest on the shoulders of people that are going to apply it - as always, an idea (strategy) however great remains an idea if you do not have the right people to understand it and execute on it ;)
Have fun
joi, 22 ianuarie 2015
Architecture definition
While reading some materials a few days ago, I ran over a cool definition of IT architecture, and I thought about sharing it with you. This is because in the past I encountered (and witnessed) difficulties while attempting to define it in a clear, concise manner. So here it goes:
Architecture
1. A formal description of a system, or a
detailed plan of the system at component level to guide its implementation
2.
The structure of components, their inter-relationships, and the principles and
guidelines governing their design and evolution over time
Have fun :)
sâmbătă, 13 decembrie 2014
IBM DB2 Replication
We recently had an architectural situation/problem to sove and that was to find a way to replicate Databases belonging to different system components between themselves, and more, to replicate all this data to an ODS belonging to our system DWH.
So I have been involved lately with looking at how we can set up a replication between different database instances we have in our solution. A strong candidate, given our requirements was DB2 SQL Replication.
We found out that DB2 10.5 has strong capabilities in this regard. One could set up a two way replication between two different database instances installed on two physically separate machines, even with connection limitations in place - I.e. One instance can not connect to the other. Furthermore, the two way replication can even be configured on the same table, with filtering in place. This means that for instance, rows matching a certain filtering criteria can be replicated from the instance A to instance B, while rows matching a different criteria can be replicated from instance B to instance A, and all of this happens with the same database table.
The connection limitation can be overcome by configuring the replication agent - that means to have these agents run on the machines that can physically connect to the other machines belonging to the system in question.
The DB2 SQL Replication can work almost instantaneously, replicating the data within a second or two timeframe.
So I have been involved lately with looking at how we can set up a replication between different database instances we have in our solution. A strong candidate, given our requirements was DB2 SQL Replication.
We found out that DB2 10.5 has strong capabilities in this regard. One could set up a two way replication between two different database instances installed on two physically separate machines, even with connection limitations in place - I.e. One instance can not connect to the other. Furthermore, the two way replication can even be configured on the same table, with filtering in place. This means that for instance, rows matching a certain filtering criteria can be replicated from the instance A to instance B, while rows matching a different criteria can be replicated from instance B to instance A, and all of this happens with the same database table.
The connection limitation can be overcome by configuring the replication agent - that means to have these agents run on the machines that can physically connect to the other machines belonging to the system in question.
The DB2 SQL Replication can work almost instantaneously, replicating the data within a second or two timeframe.
Abonați-vă la:
Postări (Atom)