- I cannot stress this enough: Keep working to clarify your understanding of the desired solution. If you come from a development background, your disposition is to start working on a solution from the moment that the problem is stated. The effect that this has is that the rest of the conversation sometimes gets tuned out while your mind turns to solving the problem that you have heard. It is important to resist this urge and pay attention, so that you can understand what the person is saying. Ask questions, and challenge the things that you do not understand.
- In India, the general answer was always immediately, "Yes, it can be done," and then the developers would go off to huddle and try to figure out what they thought was being asked for in the solution. In Eastern Europe, every request was responded to with a barrage of questions, and unclear ideas were challenged until everyone had a clear understanding of the desired solution.
- Communications skills are the skills that I work on the most, because they are the most critical for an architect. Without top communications skills, it's going to be difficult to get your vision into the heads of others. The highest responsibility of an architect is to communicate the solution to the business leaders, technical leaders, and any other interested parties in a language that they understand.
- Architects must have a mastery of three languages: business language, for communicating with the business people; industry language, for communicating in the vernacular of the vertical; and technical language, for communicating to the technical leadership and the developers.
- You must become familiar with the domain in which you will be developing a solution. I believe that there is a tremendous benefit to having experience in multiple industries and domains. This allows you to be like a bumble-bee and cross-pollinate the best ideas across industries. I have found also that the DNA of most architects contains a hunger for knowledge in a broad range of subject areas. Architects are interested in knowing about things and understanding how things work. Architects can then synthesize this knowledge into creating solutions.
- As architects, our minds can be far into the future (as they should be), but we also should not assume that the rest of the team can see that far. We must communicate, educate, and mentor the team to our level of understanding, so that they can understand the full vision. Be like a U.S. Marine: Leave no one behind.
- I wear a Microsoft Xbox 360 wristband that reads, "Challenge Me"—a statement that I think gets to the heart of what drives a solutions architect. IT solutions architecture is a constantly evolving field, with an ever-increasing set of new challenges. Albert Einstein once said, "You cannot solve tomorrow's problems with today's level of thinking." We must always be striving to take it to the next level. This has been what has driven me for the past 25 years in IT, and will continue to drive me into the future.
- The DNA of an architect is to strive to understand the problem, envision the solution, and then communicate the vision to the folks who will implement the solution. Educate and mentor your team, so that everyone comes away with the same vision.
Critical-Thinking Questions
- Are you listening to the customer? I mean, really listening to the customer? Are you asking questions to clarify the problem? Are you willing to stay in the envisioning phase until everything is clear?
- What are you going to do today, to sharpen your communication skills?
- Are you stepping back to see the big picture? How far into the future do you see this vision? Can you communicate this vision?
- Are you taking the time to bring the team along? Are you making sure that your team understands the vision?
Source:
- Are you listening to the customer? I mean, really listening to the customer? Are you asking questions to clarify the problem? Are you willing to stay in the envisioning phase until everything is clear?
Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts
Sunday, 30 August 2009
What seasoned Architects say about the craft
Saturday, 29 August 2009
Zachman Framework
- One of the popular frameworks originated at IBM and is called the Zachman Framework. The Zachman Framework predated the popularity of object orientation and took the perspective of separating data from process.
- The Zachman Framework formed a matrix of architectural descriptions that are also organized in terms of levels.
- There are five levels of description above the information system implementation.
- They range from architectural planning done by individual programmers at the finest grain to the overall enterprise requirements from the investors' perspective of the information system.
- In total, the Zachman Framework identifies thirty architectural specifications, which provide a complete description of the information system. In practice, no real-world project is capable of creating these thirty or more detailed plans and keeping them all in synchronization.
- When the Zachman Framework is applied, systems architects partition the viewpoint into various categories and create architectural specifications that cover some or all of the different Zachman descriptions without having to create the large number of individual specification documents that the Zachman Framework spans.
- There are five levels of description above the information system implementation.
The need for Software Architecture
To accommodate system complexities in the world of distributed processing, Architects have three new needs:
- First, architects need the ability to separate complex concerns, in particular to separate concerns about business-application functionality, from concerns about distributed-system complexity.
- Problems and challenges of distributed computing have nothing to do fundamentally with business-application functionality.
- In a typical application, 70% of application code is infrastructure. Some of this code is unique to the application even though it might not directly address business requirements. By separating concerns, developers can focus on the business functionality that is the true purpose of the information system.
- Problems and challenges of distributed computing have nothing to do fundamentally with business-application functionality.
- Software architects also need the ability to future-proof the information systems that they are planning.
- It is important to accommodate commercial technology evolution, which is known to be accelerating and provides substantial challenges for architects and developers.
- Future-proofing also requires the ability to adapt to new user requirements, since requirements do change frequently and account for a majority of system software costs over the life cycle.
- It is important to plan information systems to support the likely and inevitable changes that users will require in order to conduct business.
- It is important to accommodate commercial technology evolution, which is known to be accelerating and provides substantial challenges for architects and developers.
- A third need for software architects is the ability to increase the likelihood of system success.
- Corporate developers to date have had a very poor track record of creating successful systems.
- The software architect is responsible for planning systems with the maximum probability of delivering success and key benefits for the business.
- Through proper information technology planning, it is possible to increase the likelihood of system delivery on time and on budget.
- Corporate developers to date have had a very poor track record of creating successful systems.
Open Distributed Processing
- Among the various architectural approaches, a useful international standard, the Reference Model for Open Distributed Processing (RM-ODP), defines what information systems architecture means [ISO 1996].
- RM-ODP defines five essential viewpoints for modeling systems architecture:
- Enterprise viewpoint
- Information viewpoint
- Computational viewpoint
- Engineering viewpoint
- Technology viewpoint
- Enterprise viewpoint
- The five viewpoints provide a comprehensive model of a single information system, with each viewpoint being a perspective on a single information system. The set of viewpoints is not closed, so that additional viewpoints can be added as the needs arise.
- Another of their purposes is to provide information descriptions that address the questions and needs of particular stakeholders in the system.
- By standardizing five viewpoints, RM-ODP is claiming that these five stakeholder perspectives are sufficient for resolving both business functionality and distributed systems issues in the architecture and design of information systems.
- Another of their purposes is to provide information descriptions that address the questions and needs of particular stakeholders in the system.
- The enterprise viewpoint of the RM-ODP takes the perspective of a business model.
- Managers and end users in the business environment should be able to understand the enterprise models readily.
- The enterprise viewpoint ensures that business needs are satisfied through the architecture and provides a description that enables validation of these assertions with the end users.
- Managers and end users in the business environment should be able to understand the enterprise models readily.
- The information viewpoint defines the universe of discourse in the information system.
- The perspective is similar to the design information generated by a database modeler.
- The information viewpoint is a logical representation of the data and processes on data in the information system.
- The information viewpoint is an object-oriented logical model of the information assets in the business and how these assets are processed and manipulated.
- The perspective is similar to the design information generated by a database modeler.
- The computational viewpoint partitions the system into software components that are capable of supporting distribution.
- It takes the perspective of a designer of application program interfaces for component-ware.
- The computational viewpoint defines the boundaries between the software elements in the information system.
- Generally, these boundaries are the architectural controls that ensure that the system structure will embody the qualities of adaptability in management of complexity that are appropriate to meet changing business needs and incorporate the evolving commercial technology.
- It takes the perspective of a designer of application program interfaces for component-ware.
- The engineering viewpoint of RM-ODP exposes the distributed nature of the system.
- Its perspective is similar to that of an operating system engineer who is familiar with the protocol stacks and allocation issues necessary to define the distributed processing solutions for the information system.
- Its perspective is similar to that of an operating system engineer who is familiar with the protocol stacks and allocation issues necessary to define the distributed processing solutions for the information system.
- The technology viewpoint defines the mappings between the engineering objects and other objects designed to specific standards and technologies including product selections.
- The viewpoint is similar to that of a network engineer who is familiar with the commercially available protocol standards and products that are appropriate selections to configure the information system.
The RM-ODP viewpoints enable the separation of concerns that divide the business and logical functionality of the system from the distributed computing and commercial technology decisions of the architecture.
Friday, 10 October 2008
Business Logic in C# or T-Sql?
This has been a topic of debate for a long time. If you think this discussion is trivial, you need to evolve. Read on if you
think you got something to think. Practically developers, and designers prefer to use stored procedures simply because of one of the following reasons:
- Code looks good! They get a feeling that at least they have done something right in their life. They keep ridiculing others for having used in-line queries. They once read somewhere that SPs are the way to go.
- The above category is the follower - mindless follower. They are hard to convince and they will follow the same practice for years. Never mind. They also came to know in their college days that SPs are "precompiled", "fast", and "secure". They won't be able to tell you the whys and hows of things.
- Some experienced and good developers attribute the usage of SPs over parametrized queries by saying that it saves you a lot of Network bandwidth, and gives you a single point of failure. You know where things can go wrong.
- The flag bearers of business-logic-in-application-language-like-C# will tell you that the purpose of an RDBMS is to store data, and the act of manipulating it should be done on a higher level language. Languages like C# arm you with better weapons than T-Sql could ever do. T-Sql is Set based and Procedural thus monolithic. You are not living in caves anymore, are you?
- What about Sql injection attacks? They are dreaded weapons of hackers. How does parametrized query work this out? Well, they are as safe as SPs. Both are parametrized, aren't they? Its different that in-line queries. In-line queries are prone to attacks. However, there are ways to break into SPs as well, so you are not safe anyways!
- Are you talking about doing away with SPs altogether? Certainly not.
You need to decide whats best for the purpose. CRUD operations doesn't seem logical to me anymore. Imagine having a about 100 normalised tables in your database. Would you like to have 100*4 SPs doing the normal Insert, Update, Select and Delete for you? Doesn't seem so convincing. Moreover, the performance benefits of SPs and queries have been diminishing since Sql Server 7.0.
As per books online:
SQL Server 2000 and SQL Server version 7.0 incorporate a number of
changes to statement processing that extend many of the performance
benefits of stored procedures to all SQL statements. SQL Server 2000
and SQL Server 7.0 do not save a partially compiled plan for stored
procedures when they are created. A stored procedure is compiled at
execution time, like any other Transact-SQL statement. SQL Server 2000
and SQL Server 7.0 retain execution plans for all SQL statements in the
procedure cache, not just stored procedure execution plans.
- If you are planning to be object based and enjoy the rich benefits of C# as a language you must consider LINQ, or any other efficient O/R mapper like NHibernate. You will start loving it. You will love the feeling of having used pragmatic best practices and approaches.
- If you have Business Logic written in C# it implies that you can do Unit Testing with Code Coverage. If you need to traverse the rows its much easier, as it doesn't have to create #Temp tables in tempDB for Cursors. The DBA is no longer required to write complicated, hard to maintain thousands of lines of monolithic code. He can focus on database management, fine tuning, backup, replication and other important stuff! You don't need to explain the business to your DBAs. Let them be specialised in what they are doing.
- I am not sure how successfully it isolates dependency on a platform(like Oracle or Sql Server), but it does relieve you of maintaining tons of unnecessary SPs.
- Bad C# coding is certainly not a replacement of SPs. If you are writing business logic in a highly evolved language like it, you need to make sure that you are following best coding practices and patterns. If you end up writing monolithic procedural code in C#, you need to evolve before you can understand the true benefits of this discussion.
- What about debugging? I don't think that's a big deal. You can use Sql Profiler for the parameters. Agreed that you can't have IDE like debugging but Sql Server IDE is sufficient to trace a bug. You can also unit test the output generated from the database in your application with NUnit. So if you have good coverage of the SP side code, you will get to know what all you have broken as a result of the changes you made. Neat. So, this doesn't convince me to port my business logic to C#.
- SPs can't be replaced in Data driven applications like report generators, but its advisable to code the business logic in C# for applications that do data manipulation like a Financial calculator!
You may consider reading the following articles for more details.
Dude, where's my business logic?
Stored procedures are bad, m'kay?
This one is interesting because it has people fighting for their favorite approach.
Who Needs Stored Procedures, Anyways?
My take on this: Be pragmatic. Be need driven. Be domain driven.
C#: Could be any programming language.
think you got something to think. Practically developers, and designers prefer to use stored procedures simply because of one of the following reasons:
- Code looks good! They get a feeling that at least they have done something right in their life. They keep ridiculing others for having used in-line queries. They once read somewhere that SPs are the way to go.
- The above category is the follower - mindless follower. They are hard to convince and they will follow the same practice for years. Never mind. They also came to know in their college days that SPs are "precompiled", "fast", and "secure". They won't be able to tell you the whys and hows of things.
- Some experienced and good developers attribute the usage of SPs over parametrized queries by saying that it saves you a lot of Network bandwidth, and gives you a single point of failure. You know where things can go wrong.
- The flag bearers of business-logic-in-application-language-like-C# will tell you that the purpose of an RDBMS is to store data, and the act of manipulating it should be done on a higher level language. Languages like C# arm you with better weapons than T-Sql could ever do. T-Sql is Set based and Procedural thus monolithic. You are not living in caves anymore, are you?
- What about Sql injection attacks? They are dreaded weapons of hackers. How does parametrized query work this out? Well, they are as safe as SPs. Both are parametrized, aren't they? Its different that in-line queries. In-line queries are prone to attacks. However, there are ways to break into SPs as well, so you are not safe anyways!
- Are you talking about doing away with SPs altogether? Certainly not.
You need to decide whats best for the purpose. CRUD operations doesn't seem logical to me anymore. Imagine having a about 100 normalised tables in your database. Would you like to have 100*4 SPs doing the normal Insert, Update, Select and Delete for you? Doesn't seem so convincing. Moreover, the performance benefits of SPs and queries have been diminishing since Sql Server 7.0.
As per books online:
SQL Server 2000 and SQL Server version 7.0 incorporate a number of
changes to statement processing that extend many of the performance
benefits of stored procedures to all SQL statements. SQL Server 2000
and SQL Server 7.0 do not save a partially compiled plan for stored
procedures when they are created. A stored procedure is compiled at
execution time, like any other Transact-SQL statement. SQL Server 2000
and SQL Server 7.0 retain execution plans for all SQL statements in the
procedure cache, not just stored procedure execution plans.
- If you are planning to be object based and enjoy the rich benefits of C# as a language you must consider LINQ, or any other efficient O/R mapper like NHibernate. You will start loving it. You will love the feeling of having used pragmatic best practices and approaches.
- If you have Business Logic written in C# it implies that you can do Unit Testing with Code Coverage. If you need to traverse the rows its much easier, as it doesn't have to create #Temp tables in tempDB for Cursors. The DBA is no longer required to write complicated, hard to maintain thousands of lines of monolithic code. He can focus on database management, fine tuning, backup, replication and other important stuff! You don't need to explain the business to your DBAs. Let them be specialised in what they are doing.
- I am not sure how successfully it isolates dependency on a platform(like Oracle or Sql Server), but it does relieve you of maintaining tons of unnecessary SPs.
- Bad C# coding is certainly not a replacement of SPs. If you are writing business logic in a highly evolved language like it, you need to make sure that you are following best coding practices and patterns. If you end up writing monolithic procedural code in C#, you need to evolve before you can understand the true benefits of this discussion.
- What about debugging? I don't think that's a big deal. You can use Sql Profiler for the parameters. Agreed that you can't have IDE like debugging but Sql Server IDE is sufficient to trace a bug. You can also unit test the output generated from the database in your application with NUnit. So if you have good coverage of the SP side code, you will get to know what all you have broken as a result of the changes you made. Neat. So, this doesn't convince me to port my business logic to C#.
- SPs can't be replaced in Data driven applications like report generators, but its advisable to code the business logic in C# for applications that do data manipulation like a Financial calculator!
You may consider reading the following articles for more details.
Dude, where's my business logic?
Stored procedures are bad, m'kay?
This one is interesting because it has people fighting for their favorite approach.
Who Needs Stored Procedures, Anyways?
My take on this: Be pragmatic. Be need driven. Be domain driven.
C#: Could be any programming language.
Friday, 3 October 2008
Must Haves
Following is the list of must-haves; most of the Architects are aware of it. However, if you are an aspiring architect you should start from here.
Do remember that there are two ways of achieving a result: The easier way that always looks easy; and the not-so-easier-looking way which is actually fun and easy to walk on. If you are passionate about doing things in style, and quickly, and you want to be in complete control, always follow the industry best practices. Always look out for something new, keeping in mind the OO school of thought, you'll never go wrong. Frameworks will come, and go, but you need to know what triggered the need for that framework. How did they made it possible? What goes inside making such great stuff?
I am contributing in a small way a list that I have compiled today.
1. Frameworks
- Smart Client Software Factory for WinForms UI
- Web Client Software Factory for Web UI
- Spring.Net for AOP, DI and IoC, Logging, Data handling
- Unity Framework for DI and IoC
- Various Microsoft Software Factories; Enterprise Application Blocks
- Log4Net for logging
2. Tools
- Resharper for UnitTests and Code Analysis
- NCover
- NMock
- NHibernate for O/R Mapping
- Simian for Code duplication and Refactoring
- StyleCop for Code Styling
- CLR Profiler/ANTS profiler for application profiling
3. Architecture
- MVP/MVC
- Pragmatic Architecture
- SOA
4. Software Engineering
- Extreme Programming
- Agile Methodology
5. Books
- Head First Design Patterns
- Head First OOAD
- Code Complete 2
- Patterns of Enterprise Application Architecture
- Test Driven Development
- Domain Driven Develeopment
6. Practices
- TDD
- DDD
- MDD
7. Blogs
Top 100 Blogs ever!!!
Top 100 Software Engineering books ever!!!
Do remember that there are two ways of achieving a result: The easier way that always looks easy; and the not-so-easier-looking way which is actually fun and easy to walk on. If you are passionate about doing things in style, and quickly, and you want to be in complete control, always follow the industry best practices. Always look out for something new, keeping in mind the OO school of thought, you'll never go wrong. Frameworks will come, and go, but you need to know what triggered the need for that framework. How did they made it possible? What goes inside making such great stuff?
I am contributing in a small way a list that I have compiled today.
1. Frameworks
- Smart Client Software Factory for WinForms UI
- Web Client Software Factory for Web UI
- Spring.Net for AOP, DI and IoC, Logging, Data handling
- Unity Framework for DI and IoC
- Various Microsoft Software Factories; Enterprise Application Blocks
- Log4Net for logging
2. Tools
- Resharper for UnitTests and Code Analysis
- NCover
- NMock
- NHibernate for O/R Mapping
- Simian for Code duplication and Refactoring
- StyleCop for Code Styling
- CLR Profiler/ANTS profiler for application profiling
3. Architecture
- MVP/MVC
- Pragmatic Architecture
- SOA
4. Software Engineering
- Extreme Programming
- Agile Methodology
5. Books
- Head First Design Patterns
- Head First OOAD
- Code Complete 2
- Patterns of Enterprise Application Architecture
- Test Driven Development
- Domain Driven Develeopment
6. Practices
- TDD
- DDD
- MDD
7. Blogs
Top 100 Blogs ever!!!
Top 100 Software Engineering books ever!!!
Subscribe to:
Posts (Atom)